3

Each time electricity goes down, my desktop (without UPS) loses some temporary information.

  • Opera can lose settings, history, cache, or mail accounts (Thanks heavens I was wise to use IMAP). Partially or all together.
  • a whole file (complete and save) in Geany appeared empty (and I didn't commit it to Git)
  • rhythmbox lost all podcasts subscription data

I'm afraid there are other losses I just didn't see.

What's the reason? A memory files cache, a mem-disk? Or non-atomic file writes in xfs? I have Ubuntu 9.10 and XFS on both / and /home partitions.

Is ext4 safer in such circumstances? I've seen ext3 is faster. Is it as safe as *4?

Given that the apartment I rent is connected to a common bus and 1 safety switch for several apartments, and the neighbors - alone or together - overload it at least once every week, the lights go down often enough for this to be an issue.

quack quixote
  • 43,504
culebrón
  • 500

4 Answers4

6

XFS is and always has been a journalling file system. It does not truncate files to a zero length and is the base file system for many enterprise storage appliances.

You do need correctly configured hardware (specifically to make sure volatile write caches are correctly handled in your storage with the barrier mount options).

If you see data loss on any file system, please open a bug report with either your vendor or the upstream developers of the specific file system so we can investigate and try to correct any issue.

Thanks!

Ric Wheeler
  • 61
  • 1
  • 2
5

Answer Updated...

XFS is not a data journaling filesystem, such as ext3 and ext4, it is a meta-data journaling filesystem. The result is a trade-off that (usually) favors speed over reliability.

This article has a good discussion of the current state of XFS. When reading, keep in mind all filesystems are compromises between speed and reliability.

Given your lack of control of the situation, you are a good candidate for buying a small UPS.

kmarsh
  • 4,998
2

We have been using XFS on one of our x86 products and people typically just power off the unit w/o proper shutdown. Across say 8 machines running all week we see at least 2-3 bricking failures, ie the unit ceases to boot into the os, per week that look as follows: [note: this is being mounted off of a USB drive to read the details]

[  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
Remo Dubler
  • 21
0

for the record, i still frequently see this issue on vms years after...

the bug is not acknowleged by pretty much anyone and most likely comes from idiotic reordering that occur either in the linux vfs layer or possibly in my case in vmware since i've only observed this on vms.

basically the filesystem writes the data to a block and then changes the metadata mapping to point to that block rather than the previously used one, which is then freed.

when operations get randomly reordered in the linux vfs layer in some kind of messy way that involves issuing braind dead reordered transactions while hoping barriers set in the wrong places will help, and additionally using vmware which ignores said barriers, there are little chances things will not end up broken.

skullnobrains
  • 1