svn commit: r230252 - head/sys/fs/tmpfs
kostikbel at gmail.com
Tue Jan 24 10:21:13 UTC 2012
On Mon, Jan 23, 2012 at 11:05:42PM +0200, Mikolaj Golub wrote:
> On Mon, 23 Jan 2012 17:34:57 +0200 Jaakko Heinonen wrote:
> JH> On 2012-01-22, Mikolaj Golub wrote:
> >> Also, may be we should allow remounting ro (and may be some othe options) for
> >> tmpfs?
> JH> Yes, the patch below does that. I suspect that flipping the MNT_RDONLY
> JH> flag may be enough for tmpfs but I am not sure.
> I see two issues with this patch:
> 1) 'mount -u -o rw /mnt' does not upgrade to rw, although it returns success.
> 2) if you have a file open for write, after remounting ro you still can write
> to the file. The expected behaviour: remount fails with EBUSY if force option
> is not specified; after remounting with force writing to the fail fails with EIO.
> I think when remounting ro you should call vflush(), something like below:
> flags = WRITECLOSE;
> if (mp->mnt_flag & MNT_FORCE)
> flags |= FORCECLOSE;
> error = vflush(mp, 0, flags, curthread);
> if (error != 0)
> return (error);
> mp->mnt_flag |= MNT_RDONLY;
> and when upgrading to rw reset MNT_RDONLY flag:
> mp->mnt_flag &= ~MNT_RDONLY;
> I have no idea if something else is needed for tmpfs.
Yes, this is needed but not enough.
Since other writeable opens may happen during the vflush(), you might still
end up with the mount point which is not safe to set MNT_RDONLY flag.
FFS suspends the writes on the mp while doing remount. Other filesystems
like tmpfs and nfs could also perform suspend during remounts and unmounts,
but the complications are the atime and deferred inactivations. See
ufs/ffs/ffs_snapshot.c:process_deferred_inactive(), the handling of
IN_LAZYACCESS and ufs_inactive().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20120124/50f8a097/attachment.pgp
More information about the svn-src-head