每次断电，我的台式机（没有 UPS）就会丢失一些临时信息。
- Opera 可能会丢失设置、历史记录、缓存或邮件帐户（感谢上帝，我明智地使用了 IMAP）。部分或全部。
- Geany 中的整个文件（完成并保存）显示为空（而且我还没有将其提交给 Git）
- rhythmbox 丢失了所有播客订阅数据
我担心还有其他我没有发现的损失。
原因是什么？内存文件缓存，内存磁盘？或者非原子文件写入軟體系我有 Ubuntu 9.10 和西弗斯在/和/home分区上。
是ext4在这种情况下更安全吗？我见过 ext3 更快。它和 *4 一样安全吗？
鉴于我租住的公寓连接到一条公共总线和为几间公寓提供的 1 个安全开关，并且邻居们（单独或一起）每周至少会使其超载一次，因此灯光经常熄灭，这会成为一个问题。
答案1
答案已更新...
XFS 不是一个数据日志文件系统（例如 ext3 和 ext4），它是一个元数据日志文件系统。其结果是（通常）速度比可靠性更重要。
本文对 XFS 的当前状态进行了很好的讨论。阅读时，请记住所有文件系统都是在速度和可靠性之间进行折衷。
鉴于您无法控制局面，您很适合购买小型 UPS。
答案2
XFS 一直以来都是一个日志文件系统。它不会将文件截断为零长度，并且是许多企业存储设备的基础文件系统。
您确实需要正确配置的硬件（特别是确保使用屏障安装选项在存储中正确处理易失性写入缓存）。
如果您发现任何文件系统上出现数据丢失，请向您的供应商或特定文件系统的上游开发人员提交错误报告，以便我们调查并尝试纠正任何问题。
谢谢！
答案3
我们一直在我们的一款 x86 产品上使用 XFS，人们通常只是关闭设备，而不是正常关机。假设有 8 台机器运行一周，我们每周至少会看到 2-3 次变砖故障，即设备停止启动操作系统，如下所示：[注意：这是从 USB 驱动器安装的，以阅读详细信息]
[ 239.962783] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 240.089559] usb 1-2: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.08
[ 240.090356] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 240.091058] usb 1-2: Product: External
[ 240.091426] usb 1-2: Manufacturer: JMicron
[ 240.091834] usb 1-2: SerialNumber: xxxxxxxxxxxxxx
[ 240.150714] usbcore: registered new interface driver usb-storage
[ 240.169022] scsi host6: uas
[ 240.169401] usbcore: registered new interface driver uas
[ 240.179711] scsi 6:0:0:0: Direct-Access JMicron Tech 0208 PQ: 0 ANSI: 6
[ 240.191334] sd 6:0:0:0: Attached scsi generic sg0 type 0
[ 242.191630] sd 6:0:0:0: [sda] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB)
[ 242.192377] sd 6:0:0:0: [sda] 4096-byte physical blocks
[ 242.203170] sd 6:0:0:0: [sda] Write Protect is off
[ 242.203644] sd 6:0:0:0: [sda] Mode Sense: 6b 00 00 08
[ 242.214115] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 242.225350] sd 6:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[ 242.262196] sda: sda1 sda2 sda3 sda4
[ 242.312725] sd 6:0:0:0: [sda] Attached SCSI disk
[ 242.727294] XFS (sda4): Mounting V5 Filesystem
[ 242.741473] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none.
[ 242.742939] ext4 filesystem being mounted at /run/media/core/boot supports timestamps until 2038 (0x7fffffff)
[ 243.288717] XFS (sda4): Starting recovery (logdev: internal)
[ 243.453271] XFS (sda4): Metadata corruption detected at xfs_dir3_leaf_check_int+0x94/0xe0 [xfs], xfs_dir3_leaf1 block 0x5bbe0c8
[ 243.454681] XFS (sda4): Unmount and run xfs_repair
[ 243.455168] XFS (sda4): First 128 bytes of corrupted metadata buffer:
[ 243.455801] 00000000: 00 00 00 00 00 00 00 00 3d f1 00 00 09 32 6a 96 ........=....2j.
[ 243.456562] 00000010: 00 00 00 00 05 bb e0 c8 00 00 00 2b 00 00 4a c5 ...........+..J.
[ 243.457353] 00000020: 91 06 78 ff f7 7e 4a 7d 8d 53 86 f2 ac 47 a8 23 ..x..~J}.S...G.#
[ 243.458139] 00000030: 00 00 00 00 06 00 00 80 00 68 00 00 00 00 00 00 .........h......
[ 243.458910] 00000040: 00 00 00 2e 00 00 00 08 00 00 17 2e 00 00 00 0a ................
[ 243.459710] 00000050: 02 7a d9 e1 00 00 03 a8 05 cc 80 d3 00 00 01 f4 .z..............
[ 243.460494] 00000060: 08 56 88 2d 00 00 00 b0 0e 33 12 56 00 00 02 e0 .V.-.....3.V....
[ 243.461264] 00000070: 0e d7 cd 89 00 00 01 b8 14 a5 56 6a 00 00 01 ec ..........Vj....
[ 243.462043] XFS (sda4): Corruption of in-memory data (0x8) detected at __xfs_buf_submit+0x5e/0x1b0 [xfs] (fs/xfs/xfs_buf.c:1514). Shutting down filesystem.
[ 243.463670] XFS (sda4): Please unmount the filesystem and rectify the problem(s)
[ 243.475084] XFS (sda4): log mount/recovery failed: error -117
[ 243.475912] XFS (sda4): log mount failed
答案4
记录显示，几年后我仍然经常在 vms 上看到这个问题……
几乎没有人承认这个错误，它很可能来自于在 linux vfs 层或者在我的情况下在 vmware 中发生的愚蠢的重新排序，因为我只在 vms 上观察到了这个问题。
基本上，文件系统将数据写入一个块，然后更改元数据映射以指向该块而不是以前使用的块，然后释放该块。
当操作在 linux vfs 层以某种混乱的方式随机重新排序时，就会涉及发出无意义的重新排序的交易，同时希望在错误的地方设置的障碍会有所帮助，再加上使用忽略所述障碍的 vmware，事情最终被破坏的可能性很小。