Date: Sun, 2 Dec 2007 14:53:34 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: brde@optusnet.com.au Cc: freebsd-fs@FreeBSD.org Subject: Re: File remove problem Message-ID: <200712022253.lB2MrYMq037092@gw.catspoiler.org> In-Reply-To: <20071202193924.P1745@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 Dec, Bruce Evans wrote: > So it should be safe to remove all the r/o checks in ufs_inactive() after > fixing the other bugs. ffs_truncate alread panics if fs_ronly, but only > in some cases. In particular, it doesn't panic for truncations that don't > change the file size. Such truncations aren't quite null, since standards > require [f]truncate(2) to mark the ctime and mtime for update. > ffs_truncate() sets the marks, which is correct for null truncations from > userland but not ones from syncer internals. Setting of the marks when > fs_ronly is set should cause panics later (my patch has a vprint() for it). I think the MNT_RDONLY check in ufs_itimes_locked() should be also be changed to look at fs_ronly and panic if any marks are set. This will require some changes to add some early MNT_RDONLY checks. In particular, ffs_read() and ffs_extread() need to check MNT_RDONLY in addition to MNT_NOATIME (as is already done in vfs_mark_atime()). This also looks like it should be a reasonable optimization for read-only file systems that should eliminate unnecessary work at the lower levels of the code. The early IN_ACCESS flag setting in ufs_setattr(), before the MNT_RDONLY check, appears to be protected by the MNT_RDONLY check in vfs_mark_atime().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712022253.lB2MrYMq037092>