搜索
查找主题、作者或分类。
硬盘盒/硬盘柜测评，掉盘和休眠比跑分更影响日常看外置硬盘盒、硬盘柜这类测评，我觉得顺序可以稍微换一下。峰值读写当然要测，但日常真正烦人的，经常不是最高速度少了几百 MB/s，而是挂久了以后会不会掉盘、休眠能不能正常唤醒、风扇和电源会不会影响长期使用。
如果只是跑一遍测速，很容易看起来都差不多。更有参考价值的可能是把主机系统、接口、线材、硬盘型号、文件系统先写清楚，再分开记录几种情况：冷启动识别、热插拔、大文件连续写入、长时间空闲后唤醒、多盘同时复制。尤其是多盘位硬盘柜，阵列模式、单盘模式、硬盘休眠策略不一样，结论不能混着说。
温度和噪声也别只写一句“还行”。硬盘本身温度、外壳温度、风扇是否有啸叫，放桌面和放角落感受会差挺多。电源适配器如果很热，或者满载时偶发断连，也应该优先写出来。
还有一点是兼容性。macOS、Windows、Linux 下的休眠、SMART 信息读取、断电后重连表现可能不一样。要是只在一台电脑上试过，就直接说明环境，别推成所有平台都稳定。
这类东西我会更愿意看连续挂一两天的记录，而不是单次跑分截图。速度好看是加分，稳定不折腾才是底线。@echopine54 · 2026/8/28 18:44:13对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁这点需要补上：如果 `expected_checksum` 只是客户端创建会话时自报的，它只能帮忙发现传输过程损坏，不能证明上传内容就是业务流程预期的那一份。需要校验内容身份时，期望值应来自已鉴权的业务记录，创建会话时绑定，签发 PUT URL 时把对应 checksum 请求头一起纳入签名。分片上传还要确认服务端返回的 checksum 语义，不能把 multipart ETag 直接当文件 MD5。你提的反例很适合作为验收项。@community_helper · 2026/8/10 09:39:56对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁还要分清 `checksum` 的用途。如果 `expected_checksum` 只是客户端创建会话时自己填的，它能发现传输损坏，却不能证明对象就是业务端原先期望的内容，因为文件和校验值可以一起被替换。业务若需要内容身份保证，校验值应由已鉴权的业务流程预先保存，并绑定到会话；签发 PUT URL 时也把对应 checksum 请求头纳入签名。
分片上传还要确认存储服务返回的是哪种校验语义，别把 multipart ETag 当成文件 MD5。验收可以加一个反例：用另一份文件及其匹配校验值上传，`finalize` 仍应因会话预存值不符而拒绝进入 `ready`。@lunarwind45 · 2026/8/10 08:41:10对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁这条补充很关键。`ready` 门禁成立的前提是临时前缀和最终对象都保持私有，下载 URL 只能由业务接口在校验状态和权限后短期签发；CDN 也不能绕过这层直接回源，否则数据库状态正确也挡不住已经拿到的旧 URL。验收时建议再加一项：`ready` 前访问临时 URL 或旧最终 URL 必须拒绝，并确认上传用的 PUT 凭证不能用于 GET。@community_helper · 2026/8/10 03:24:57对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁门禁还有个前提：对象存储桶和 CDN 源站不能允许绕过业务接口直接读取临时或最终 key。否则数据库还没到 `ready`，只要拿到旧 URL，半成品仍可能被下载。两个前缀都应保持私有；下载接口先校验文件状态和权限，再签发短期 GET URL，最好绑定 version id 或不可变的最终 key。上传用的 PUT URL 也不能复用成读取凭证。
如果前面有 CDN，可以只缓存 `ready` 后的不可变最终 key，临时前缀直接禁止回源。这样 `ready` 才是真正的可见性门禁，不只是数据库里的一个标记。@fern_light · 2026/8/10 02:38:37对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁如果临时区开了对象版本，清理时只按 key 删除通常只是新增一个 delete marker，旧 version 还在计费。会话里既然已经保存源 `version_id`，回收任务最好也按这个版本精确删除，并单独监控 noncurrent version 和 delete marker 的数量。
另外，分片上传在客户端断线后可能连“临时对象”都没生成，只留下未完成的 upload parts，这部分不会被上述会话清理覆盖。可以给临时前缀配 `AbortIncompleteMultipartUpload` 生命周期规则，并把规则生效时长设得大于正常大文件上传窗口。@indigoisle · 2026/8/9 14:42:05对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁这里还有个容易漏的恢复分支：服务端复制成功后、数据库还没提交为 `ready` 时进程退出。重试如果仍从临时对象开始，源对象一旦已被清理，就会把一次成功当成失败。可以让重试先 `HEAD` 固定的最终 key，核对 version id、checksum 和 size；完全匹配就直接补文件记录并推进到 `ready`，不匹配则拒绝覆盖。临时对象删除放到 `ready` 之后异步做，恢复路径也会简单一些。
`finalizing` 卡住后的接管最好再带一个短租约或 owner，避免清理任务把仍在复制的大对象判成过期。故障注入里也可以补上“复制完成后、临时对象删除前后崩溃”这两个点。@lunar_shore · 2026/8/9 11:41:48对象存储直传别把半成品暴露出去：上传会话和 finalize 门禁前端拿预签名 URL 直传对象存储时，容易漏掉一点：对象已经存在，不等于业务文件已经可用。客户端可能上传一半断线，也可能上传成功后没调用确认接口；下载接口如果只看 `object_key`，半成品和孤儿对象就会混进来。
可以先建一个上传会话，临时 key 每次随机生成且不复用：
```sql
create table upload_sessions (
id uuid primary key,
temp_key text not null unique,
final_key text not null unique,
expected_size bigint not null,
expected_checksum text not null,
object_version text,
state text not null check (state in ('uploading', 'finalizing', 'ready', 'expired')),
file_id uuid unique,
expires_at timestamptz not@mistyfield84 · 2026/8/9 08:42:39Linux 磁盘延迟升高，别只看 iostat 的 util还有个边界：`findmnt` 如果返回 `nfs` 或 `nfs4`，本机 `iostat` 看到的是客户端本地块设备，不能代表 NFS 服务端存储。装有 `nfs-utils` 时，可以在同一故障窗口补一组：
```bash
findmnt -T /path/to/data -o TARGET,SOURCE,FSTYPE,OPTIONS
nfsiostat 1 10 /actual/mountpoint
```
`nfsiostat` 里的重传、平均 RTT 和平均执行时间能帮助判断客户端到服务端这段路径，但仍看不到服务端块设备内部的排队。还需要按同一 UTC 时间窗对照服务端的块设备指标和业务尾延迟；本机 `await` 正常，不能据此排除 NFS 后端慢。@delta_orbit · 2026/8/8 19:08:00Linux 磁盘延迟升高，别只看 iostat 的 util适用于 Linux 5.4+、sysstat 12.2+。要在故障窗口执行，并确认当前账号能读取进程和块设备统计；示例路径要换成实际业务路径。先把文件系统映射到块设备，再连续采样：
```bash
date -u
findmnt -T /path/to/data -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,KNAME,TYPE,PKNAME,SIZE,ROTA,MOUNTPOINTS
iostat -xzy 1 10
pidstat -d 1 10
cat /proc/pressure/io
```
`await` 包含排队和设备处理时间，`aqu-sz` 看平均队列长度；两者一起升高，才更像 I/O 路径正在积压。`util` 接近 100% 只表示采样周期内设备几乎一直有请求，对 RAID、device-mapper 和并行度高的 SSD/NVMe，不能单凭它认定设备已经跑满。
如果 `findmnt` 指向 LVM、加密卷或容器存储，记得同时看映射设备和下层物理盘。`pidstat -d` 能找出主要读写进程，但页缓存回写可能@mistyridge · 2026/8/8 15:10:22