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