>On Tue, Nov 10, 2009 at 4:29 AM, Nick Guenther <kou...@gmail.com> wrote:
>> So, as nicely summarized at
>> http://www.h-online.com/open/news/item/Possible-data-loss-in-Ext4-740467.html,
>> ext4 is kind of broken. It won't honor fsync and, as a /feature/, will
>> wait up to two minutes to write out data, leading to lots of files
>> emptied to the great bitbucket in the sky if the machine goes down in
>> that period. Why is this relevant to OpenBSD? Well sometimes I've been
>> writing a file in vi or mg and had my machine go down, and when it
>> comes back I find that the file is empty and I'm just trying to figure
>> out if this is just because the data wasn't fsync'd or if it's because
>> of softdep or what.
>
>softdep has that effect.  The file was created and then data written.
>But softdep cares more about the first op than the second, so there's
>a window where crashing will cause you to wake up with empty files.
>
>Without softdep, it's more likely you'll have your data (though it may
>even be the old version, and you may have to look in lost+found for
>it).  softdep works fine with fsync, but the old unix trick of write
>data then rename leads to empty files, because the rename is "sped up"
>but the data isn't.

There is a very simple explanation for why things are so.

Actual data file loss has never been what these things were coded for.

filesystem *tree and meta-data*, ie. the structure of how things are
knit together, is the main concern.  If you lose the filesystem tree
structure, you've lost all your files, not just the newest ones.
Therefore the goal is safe metadata handling.  The result is you can
lose specific data in specific (newly written to) files, but the
structure of the filesystem is consistant enough for fsck to not damage
it.

If you want to never lose data, you have an option.  Make the filesystem
syncronous, using the -o sync option.

If you can't accept the performance hit from that, then please accept
that all the work done over the ages is only on ensuring metadata-safety
for a low performance penalty.  It has never been about trying to
promise file data consistancy when that could only be achieved by
syncronous file data writing.

Reply via email to