Joel Ray Holveck <jo...@gnu.org> writes: > About five minutes ago, I realized that one problem is that I recently > installed a new disk, and forgot to enable softupdates on it (doh!). > From the little I know, I don't quite understand why softupdates is a > tunefs parameter, instead of a mount flag.
You shouldn't switch back and forth between soft updates and normal operation in a single mount session. Mount flags let you do that. Anyway, all you're actually intersted in is knowing if a crashed file system was running with soft updates before the crash, because it eliminates the need for fsck (all you need to do is recover blocks which are incorrectly marked as allocated; this can be done in the background on a live file system - maybe even by the fs code itself?) Maybe the right thing would be a "soft updates bit" similar to the dirty bit. You set the SU bit upon mounting a file system with soft updates, and clear it otherwise. If the user tries to mount a dirty SU file system, you silently clear the dirty bit, mount the file system and recover lost blocks in the background. If the user tries to mount a dirty non-SU file system, you refuse as usual. > Can a fs with softupdates > turned on in the superblock work on a non-softupdates kernel without > trouble? Yes. I believe there might be a slight performance hit, but it shouldn't be too noticeable. > If so, would it be a good idea to have newfs turn it on by > default? No, I don't think there's much point in doing that before Kirk McKusick removes the restrictions on the soft updates code. When that happens, we can make soft updates non-optional and turn on soft updates on all file systems by default. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
