当对磁盘的 SMART 检查报告坏扇区时，重要的是能够识别具有坏扇区的文件 - 并从备份中恢复它。下面，我展示了我是如何为我的 Linux/ext3 VMWARE 服务器做到这一点的——但有没有人知道这是否可以为 Windows/NTFS 做到这一点？
以下是我为 Linux/ext3 所做的：我首先要求驱动器进行硬件表面扫描（低于操作系统级别，使用驱动器上的 SMART 电路）：
vserver:~# smartctl -t long /dev/sdc
我看了结果：
vserver:~# smartctl -a /dev/sdc
...
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 1
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 9
...
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 27679 591363172
因此，一个扇区已经被标记为坏，9 个被标记为从“暂存”扇区空间替换。更重要的是，第一个不可读的逻辑块地址 (LBA) 是 591363172。
我找到了这个数字“转换”为的分区（以及其中的偏移量）：
vserver:~# fdisk -lu /dev/sdc
Device Boot Start End Blocks Id System …在我们应用程序的配置中，nginx 在gunicorn.
我们的应用程序以一般来说较小的响应来回复前端请求……但某些端点生成的响应大于一个内存页 (4K)。
发生这种情况时，nginx 会记录此警告：
an upstream response is buffered to a temporary file
/path/to/nginx/proxy_temp/4/86/0000000864 while reading upstream,
client: 1.2.3.4, server: api.ourdomain.com, request: "GET /pdf/..."
我们的 nginx 日志最终充斥着这个警告——据我所知，使这个警告从我们的日志中消失的唯一解决方案是糟糕的解决方案：
我可以将 nginx 设置proxy_max_temp_file_size为 0 - 基本上禁用大型响应的缓冲。这将停止对文件的缓冲——但这也意味着对于生成大量响应的端点（例如，生成 1-2MB 响应的 PDF 生成的端点），一个缓慢消耗的客户端会拖延相应的 gunicorn 工人......事实上，如果有是 N 个 gunicorn 工人，只需要 N 个客户端在慢速网络连接后生成 PDF，我们的应用程序就会关闭......
我可以将其proxy_buffer_size增加到 4K 以上（即一个内存页）。我很确定这会对 nginx 性能产生严重影响 - 我们 70% 的响应确实适合 4K，我们会强制 nginx 分配......什么？他们每个人都有 2MB 的缓冲区，只是为偶尔的 PDF 生成请求做好准备？ 编辑：事实上，这根本不是一个选项——迈克尔（下面）评论说，唯一允许的值是 4K 和 8K。
我可以proxy_buffering关闭 …