On Sun, Dec 11, 2011 at 11:44 AM, Joerg Sonnenberger <jo...@britannica.bec.de> 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 >> <jo...@britannica.bec.de> 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
