标签: filesystems

我想知道在我的服务器上使用 ext4 是否安全。但我听说过太多关于它的 FUD，我很担心。

我们的系统可能会丢失一些数据，这没什么大不了的。即使是一整天的数据也不会惹恼太多人。我们的系统绝对可以从延迟写入中受益。

也就是说，从备份中恢复完整的文件系统需要几天时间并且是不可接受的。

关于这个主题的任何经验或知情意见？

在大多数情况下，在 Linux 中进行递归/深层目录复制的一种好的通用方法是什么？我使用了简单的东西，比如cp -R相当复杂的cpio咒语。是否有任何显着的优势或劣势导致您偏爱其中一个？你最常使用哪一种？

我的用户 bob 无法访问他（理论上拥有）的文件。我正在运行 Fedora Core 8。显示可能比告诉更容易：

> ls -al .
total 32
drwxrwxr-x 7 bob bob 4096 May 18 14:33 .
drwxrwxr-x 4 bob bob 4096 May 12 15:44 ..
drwxr-xr-x 2 bob bob 4096 June 1 14:22 log

> cd ./log
-bash: cd: log/: Permission denied

> ls -al ./log
ls: cannot access log/..: Permission denied
ls: cannot access log/the.log: Permission denied
ls: cannot access log/.: Permission denied
total 0
d????????? ? ? ? ?            ? .
d????????? ? …

据我了解，类 Unix 操作系统上的每个文件都有一个 inode 编号（可以用“ls -i”查看），每个 inode 是一个包含文件实际数据的磁盘块列表。

是否有一个 Linux 命令将文件名作为其参数并打印出该文件的 inode 指向的磁盘块列表？

PS 有问题的文件系统是 ext3。

Linux 是否记录上次更改文件（而不是创建文件）的人？如果是这样，我如何找到它？如果没有，是否有某种监视文件的方法？

我的公司制造了一个嵌入式 Debian Linux 设备，它从内部 SSD 驱动器上的 ext3 分区启动。由于该设备是一个嵌入式“黑匣子”，它通常以粗鲁的方式关闭，只需通过外部开关切断设备的电源即可。

这通常是没问题的，因为 ext3 的日志记录使事情井然有序，所以除了偶尔丢失部分日志文件之外，事情一直在顺利进行。

但是，我们最近看到许多单元在经过多次硬电源循环后，ext3 分区开始出现结构性问题——特别是，我们在 ext3 分区上运行 e2fsck，它发现了许多类似的问题显示在此问题底部的输出列表中。运行 e2fsck 直到它停止报告错误（或重新格式化分区）会清除问题。

我的问题是……在遭受大量突然/意外关闭的 ext3/SSD 系统上看到这样的问题有什么含义？

我的感觉是这可能是我们系统中软件或硬件问题的迹象，因为我的理解是（除非出现错误或硬件问题）ext3 的日志记录功能应该可以防止此类文件系统完整性错误。（注意：我知道用户数据没有被记录在日志中，因此可能会发生被删除/丢失/截断的用户文件；我在这里专门讨论文件系统元数据错误，如下所示）

另一方面，我的同事说这是已知/预期的行为，因为 SSD 控制器有时会重新排序写入命令，这可能会导致 ext3 日志混淆。特别是，他认为，即使在正常运行的硬件和没有错误的软件的情况下，ext3 日志也只会降低文件系统损坏的可能性，并非不可能，因此我们不应该对时不时地看到这样的问题感到惊讶。

我们谁是对的？

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: …

我最近一直在阅读有关 SATA 驱动器的写入缓存、NCQ、固件错误、障碍等内容，但我不确定在发生电源故障时使我的数据安全的最佳设置是什么。

据我了解，NCQ 允许驱动器重新排序写入以优化性能，同时让内核了解哪些请求已被物理写入。

写入缓存使驱动器更快地处理请求，因为它不会等待数据写入物理磁盘。

我不确定 NCQ 和写入缓存如何在这里混合...

文件系统，特别是日志文件系统，需要确定何时写下特定请求。此外，用户空间进程使用 fsync() 强制刷新特定文件。在文件系统确定数据已写入磁盘之前，对 fsync() 的调用不应返回。

有一个功能（FUA，强制单元访问），我只在 SAS 驱动器上看到过，它强制驱动器绕过缓存并直接写入磁盘。对于其他一切，都有写屏障，这是内核提供的一种机制，可以触发驱动器上的缓存刷新。这会强制写下所有缓存，而不仅仅是关键数据，因此如果滥用会降低整个系统的速度，例如 fsync()。

然后有固件错误的驱动器，或者故意谎报数据何时被物理写入。

话虽如此.. 有几种方法可以设置驱动器/文件系统：A) NCQ 和写入缓存禁用 B) 仅启用 NCQ C) 仅启用写入缓存 D) 启用 NCQ 和写入缓存

我假设障碍已启用..顺便说一句，如何检查它们是否实际启用？

如果断电，在主动写入磁盘时，我的猜测是选项 B（NCQ，无缓存）对于文件系统日志和数据都是安全的。可能会有性能损失。

选项 D（NCQ+缓存），如果使用屏障或 FUA，对于使用 fsync() 的文件系统日志和应用程序是安全的。对于在缓存中等待的数据来说，这将是不利的，由文件系统来检测它（校验和），至少文件系统不会（希望）处于不稳定状态。在性能方面，它应该更好。

然而，我的问题是......我错过了什么吗？还有其他变量需要考虑吗？是否有任何工具可以确认这一点，以及我的驱动器是否正常运行？

这本书“的HBase权威指南”指出，

不建议在单个服务器上安装不同的文件系统。这可能会对性能产生不利影响，因为内核可能必须拆分缓冲区缓存以支持不同的文件系统。据报道，对于某些操作系统，这可能会对性能产生破坏性影响。

这真的适用于Linux吗？我从未见过超过 300 MB 的缓冲区缓存，而且大多数现代服务器都有千兆字节的 RAM，因此在不同文件系统之间拆分缓冲区缓存应该不是问题。我还缺少其他东西吗？

Ubuntu 12.04

文件系统频繁进入只读模式。首先，我读过这个问题文件系统已经经常进入只读模式。但我必须知道它是否不是由dying hard drive. 这是我的客户提供的服务器，我只是在那里运行一些node.js workers+ 一个node.js server，我正在使用mongodb.

有时（每 20-50 小时）系统突然使文件系统只读，mongodb 进程失败（由于只读 fs）并且我的节点工作人员/服务器（由 启动forever）刚刚被杀死。

这是来自 dmesg 的日志 - 我可以看到 FS 将要只读的一些错误和消息，还有一些 JOURNAL 错误，但我想找出这些错误的原因..

http://speedy.sh/Ux2VV/dmesg.log.txt

编辑

smartctl -t long /dev/sda
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.5.0-23-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

SMART support is: Unavailable - device lacks SMART capability.
A mandatory SMART command failed: exiting. To continue, add one or more '-T …

我想删除一个 nginx 缓存目录，我通过以下方式快速清除了该目录：

mv cache cache.bak
mkdir cache
service nginx restart

现在我有一个cache.bak包含 200 万个文件的文件夹。我想在不打扰服务器的情况下删除它。

一个简单的rm -rf cache.bak垃圾服务器，即使是最简单的 HTTP 响应在 rm 运行时也需要 16 秒，所以我不能这样做。

我试过了ionice -c3 rm -rf cache.bak，但没有帮助。服务器有 HDD，而不是 SSD，可能在 SSD 上，这些可能不是问题。

我相信最好的解决方案是某种限制，就像 nginx 的内置缓存管理器所做的那样。

你会如何解决这个问题？有没有什么工具可以做到这一点？

Ubuntu 16.04 上的 ext4