Brad Knowles wrote: > At 2:02 PM -0800 2002/11/25, Terry Lambert wrote: > > If you made system dumps mandatory (or marked swap with a non-dump > > header in case of panic), this still would not handle the "silent > > reboot", "double panic", or "single panic with disk I/O trashed" > > cases. 8-(. > > How about we do the safe thing, and only do background fsck if we > can prove that the system state is something where it would be > suitable? Or would that mean that we almost never do background fsck?
It would mean that you can *never* background fsck safely. The problem is that you need to distinguish a power failure, which is technically the only safe time to do it, from all other failure modes. You can distinguish, at least on R/W FS's, whether or not to do any fsck (by looking at the "clean" bit), but all other bets are off. One approach that works well for desktop systems is to implement a "soft read-only". We did this at Artisoft in 1995/1996, when we ported the VFS stacking framework to Windows 95, and first implemented a soft updates for FFS/UFS, which we ported to run on Windows 95 under the stacking framework. The way a "soft read-only" works is to leave the FS mounted read/write, and then insert at write attempts, everywhere that read-only is checked, a check for a "soft read-only" bit on the in-core superblock. Basically, we flush out all writeable state to the FS, and then set the clean bit in the superblock, and flush it to disk, if I/O on the FS has been idle for a while. Then, when someone wants to write it, we reset the "dirty" bit, flush the superblock back out to disk, and, once we know that the change has been committed to stable storage, we permit the write operation to continue. There's actually some problems that now exist in the sync code in FreeBSD that result in unnecessary writes to the disk, these days, which make it hard to implement this (the system basically sync's disk buffers that don't need to be sync'ed, at intervals); that would have to be fixed before such a system can be used. The result is a box you can just "turn off", without trashing the FS, assuming it's relatively quiescent, relative to FS writes (e.g. desktop systems, as I said at the top). Similarly, if the system were to panic, lose power, whatever, at this point, then the FS's would be clean, and come back up with no need to fsck. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
