Date: Tue, 6 Sep 2005 02:06:40 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: phk@haven.freebsd.dk Cc: current@FreeBSD.org Subject: Re: patch for ext2fs unmount problem at shutdown Message-ID: <200509060906.j8696evP032122@gw.catspoiler.org> In-Reply-To: <64186.1125996351@phk.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 Sep, Poul-Henning Kamp wrote: > In message <200509060841.j868fj1I032057@gw.catspoiler.org>, Don Lewis writes: > >>I suspect both that is one possible reason, and another reason would be >>to avoid marking the file system clean if any writes timed out. > > In that case the unmount should fail, otherwise the filesystem is > buggy. > >>> 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(). >> >>That makes sense longer term, but for quite some time we've had a number >>of users who have been rather unhappy to find out that every time they >>reboot with a mounted ext2fs file system that *all* of their file >>systems are marked dirty and require attention from fsck. > > I am really not keen on adding more magic features to the buffer cache > if we can get the same effect by taking away code. I'm not especially thrilled about it either since the buffer cache code is one of the parts of the kernel that I understand the least. This patch is pretty non-intrusive, though, because it essentially just borrows an unused flag bit. > Considering that our kernel presently tend to explode violently on > disk errors I would say that the nbusy check should just be commented > out for now and vfs_unmountall() always tried. This might be reasonable to try in HEAD, but I'm not comfortable doing it in RELENG_6 and RELENG_5. We've always skipped vfs_unmountall() if nbusy != 0, so we don't know what strange and wonderful new failure modes we might find if we do it unconditionally. Just auditing the code would be a lot of work given the number of file system types we support.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509060906.j8696evP032122>