Date: Tue, 06 Sep 2005 10:21:05 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: patch for ext2fs unmount problem at shutdown Message-ID: <64074.1125994865@phk.freebsd.dk> In-Reply-To: Your message of "Tue, 06 Sep 2005 00:57:04 PDT." <200509060757.j867v42t031957@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200509060757.j867v42t031957@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64074.1125994865>