This is a discussion on Re: File remove problem - FreeBSD ; 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 ...
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
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"