Re: Lost file-system story

[Donald Allen <donaldcallen%gmail.com@localhost>]

On Sun, Dec 11, 2011 at 11:44 AM, Joerg Sonnenberger
<joerg%britannica.bec.de@localhost> wrote:
> On Sun, Dec 11, 2011 at 11:32:51AM -0500, Donald Allen wrote:
>> On Sun, Dec 11, 2011 at 11:04 AM, Joerg Sonnenberger
>> <joerg%britannica.bec.de@localhost> wrote:
>> > On Sun, Dec 11, 2011 at 10:50:29AM -0500, Donald Allen wrote:
>> >> I repeated the test without the sync, but waited 15 minutes after
>> >> creating the new file before killing the power. When the system came
>> >> up, I got fsck errors that were fixed, and the new file I created 15
>> >> minutes before pulling the plug was not present. Whether this is
>> >> intentional or a bug, I agree with David Holland -- it's wrong and
>> >> should be fixed.
>> >
>> > I disagree. It is exactly why I use FFS with -o async -- to get a disk
>> > backed storage, that doesn't waste resources, if everything fits into
>> > memory, but falls gracefully otherwise.
>>
>> Certainly a valid requirement, but we haven't talked about what the
>> fix should be. I think it should have an adjustable sync frequency, so
>> that the user can turn a knob from "I want to lose as little as
>> possible" to "I want maximum performance". If I get my wish, you can
>> use the latter, which should set the frequency to zero.
>
> I don't see the point. Out of order meta updates can fry the file system
> at any point. Really, just don't use them if you can't recreate the
> file system freely. As has been mentioned elsewhere in the thread, the
> default mount option is *not* async.

Yes, they *can* destroy the filesystem, but in Linux ext2, they rarely
do (see what I've said about this in previous messages in this
thread), and I've started, in a small way, to build a case for NetBSD
ffs and its fsck also having a reasonable probability of surviving a
crash (what really matters is the joint probability of crashing --
very low in the case of Linux over the years -- *and* losing the
filesystem on restart).

As for the knob, it probably doesn't make sense to mount a filesystem
async and then set the knob to sync every 50 milliseconds. One isn't
going to get much of a performance benefit in return for incurring the
risk of async mounting (I would guess that the risk goes down as the
sync frequency goes up, but doesn't go to zero). If safety is one's
orientation, it would probably be better to mount default, sync, or
softdep, or use the new journaling option. But sync'ing every 5
minutes or 10 minutes might well give one the performance benefit that
brought async to consideration in the first place, while likely
limiting lost work to a 5- or 10-minute window. I say "likely",
because I emphasize again, for the umpteenth time in this discussion,
that I completely understand that async incurs the risk of losing the
whole filesystem. But if NetBSD/ffs/fsck turns out to exhibit the same
behavior as Linux/ext2 has exhibited for years, the joint probability
of crashing and incurring that loss is extremely low. And if it
happens, I can and will deal with that.

As an example, the machine I'm typing this on is running 5.1 with an
/etc/fstab that looks like this:

# NetBSD /etc/fstab
# See /usr/share/examples/fstab/ for more examples.
/dev/wd0a       /       ffs     rw,noatime              1 1
/dev/wd0b               none    swap    sw,dp           0 0
/dev/wd0e       /usr    ffs     rw,noatime              1 2
/dev/wd0f       /var    ffs     rw,noatime              1 2
/dev/wd0g       /home   ffs     rw,noatime,async        1 2
/dev/wd0b       /tmp    mfs     rw,-s=205632
kernfs          /kern   kernfs  rw
ptyfs           /dev/pts        ptyfs   rw
procfs          /proc   procfs  rw
/dev/cd0a       /cdrom  cd9660  ro,noauto

So everything has the default mounting+noatime except /home, which is
noatime,async. I routinely rsync my home directory among my many
machines, so I've got N very up-to-date backups. If I lose /home, not
that big a deal. But if the system crashes and the filesystem is
recovered, I'd like to have the option to make it a smaller deal
still, and be able to define a maximum-loss window, something smaller
than the min(time since last normal reboot, time since last rsync).

/Don



>
> Joerg