| |||||||||||||
|
| |||||||||||||
JLS2009: A Btrfs updateJLS2009: A Btrfs updatePosted Nov 1, 2009 7:51 UTC (Sun) by Cato (subscriber, #7643)In reply to: JLS2009: A Btrfs update by anton Parent article: JLS2009: A Btrfs update
Interesting example - presumably ext3 with data=journal would ensure that the data and metadata hit the disk together. This should avoid the scenario mentioned that metadata for the main and autosave files hit the disk, causing the OS to empty the autosave file, while the main file's data remains in memory and is wiped by the system crash.
(Log in to post comments)
JLS2009: A Btrfs update Posted Nov 1, 2009 19:55 UTC (Sun) by anton (subscriber, #25547) [Link] Yes, data=journal should be ok, unless they introduce one of the file system corruption bugs like one I read about (for data=journal) some years ago. I guess this was not noticed during development because it's a non-default mode, so it's tested by few (and typically those people who do use such hopefully-safer, slower features don't run bleeding-edge kernels).The former default ext3 behaviour (data=ordered) should also be ok for simple cases such as this (i.e., no overwriting of existing blocks involved). Unfortunately, Ted T'so, the current maintainer of ext3 wants to degrade ext3 default functionality to the lowest common denominator (i.e., at least as bad as UFS), with better functionality available through mount options; will this work out any better than the non-default data=journal?
|
|
||||||||||||