patch for ext2fs unmount problem at shutdown
Poul-Henning Kamp
phk at phk.freebsd.dk
Tue Sep 6 01:21:08 PDT 2005
In message <200509060757.j867v42t031957 at gw.catspoiler.org>, Don Lewis writes:
>> Why is this necessary ? As far as I know we do an orderly unmount
>> of all filesystems at shutdown, so shouldn't ext2fs release the
>> buffers at that time ?
>
>We count the busy buffers before unmounting anything, and skip the
>unmount if the count is nonzero.
I guess this has an interesting historical explanation, but I have
a hard time seeing how we could arrive at this logic if we started
from scratch today.
My best guess is that this is an attempt to detect disk errors: The
sync(2) call would push as much as possible onto disks and by
skipping the unmount we would not hang waiting for the dead disk.
I think we should do away with the nbusy check, including the 35
lines of softupdate magic and call vfs_unmountall() in all circumstances
(but retain the check for !cold, RB_NOSYNC and panic).
Instead we should add a flag to VFS_UNMOUNT that means "don't hang
forever" and use that in vfs_unmountall().
Calling sync(2) up front still makes sense as it will take advantage
of any parallism possible to multiple drives.
Poul-Henning
PS: Considering power management, sleep/suspend modes etc, it would
make sense to add a "MNT_CLEAN" flag to pass to VOP_FSYNC which
instructed the filesystem to flush everything to disk, and reset
any "dirty" flags on the disk to "clean" but leave the filesystem
mounted. (On subsequent I/O the first thing the filesystem must
do is set the dirty flag again. That way it would be as safe (as
possible) to power a sleeping/suspend machine off.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-current
mailing list