Hello lists,
I am extending this topic to LKML to post a question that goes beyond the
scope of unionfs. First, a description:
unionfs depends on filesystems being read-only returning EROFS to properly
do copyup.
Unfortunately, NFS mounts that are exported with the "ro" flag, and which
have been imported/mounted with the "rw" flag, either implicit (i.e.
automatically added by /bin/mount) or explicit using "-o rw", do return
EACCES instead of EROFS for opening already-existing files with the write
bit. Or, in other words:
# grep export /etc/exports
/export *(ro,async,no_root_squash)
# mount localhost:/export /mnt -t nfs -oro
# logout
$ cat /proc/mounts | grep nfs
localhost:/export /mnt nfs ro,v3,rsize=32768,wsize=32768,hard,tcp,lock,addr=localhost 0 0
$ ls -l /mnt/file
-rw-r--r-- 1 root root 0 Oct 27 22:42 /mnt/file
$ touch /mnt/file
touch: cannot touch `file': Read-only file system
$ strace -e trace=file touch /mnt/file
open("/mnt/file", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) =
-1 EACCES (Permission denied)
utimes("/mnt/file", NULL) = -1 EACCES (Permission denied)
...
touch: cannot touch `/mnt/file': Permission denied
If the file does not exist however, everything is ok:
$ touch /mnt/file
touch: cannot touch /mnt/file': Read-only file system
$ strace -e trace=file touch /mnt/file
open("/mnt/file", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) =
-1 EROFS (Read-only file system)
utimes("/mnt/file", NULL) = -1 ENOENT (No such file or directory)
Which brings me right to question... should mountd or knfsd be adjusted to
refuse a rw mount request if an nfs export is only available as ro? Like it is
already the case with normal block devices:
# strace -e trace=mount mount /dev/hdb /F -o rw -t iso9660
mount("/dev/hd/b", "/F", "iso9660", MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec0000,
0x8067cd0) = -1 EROFS (Read-only file system)
mount: block device /dev/hd/b is write-protected, mounting read-only
mount("/dev/hd/b", "/F", "iso9660",
MS_RDONLY|MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec0000, 0x80680c8) = 0
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
to den 27.10.2005 klokka 22:57 (+0200) skreiv Jan Engelhardt:
> # grep export /etc/exports
> /export *(ro,async,no_root_squash)
> # mount localhost:/export /mnt -t nfs -oro
> # logout
> $ cat /proc/mounts | grep nfs
> localhost:/export /mnt nfs ro,v3,rsize=32768,wsize=32768,hard,tcp,lock,addr=localhost 0 0
> $ ls -l /mnt/file
> -rw-r--r-- 1 root root 0 Oct 27 22:42 /mnt/file
> $ touch /mnt/file
> touch: cannot touch `file': Read-only file system
> $ strace -e trace=file touch /mnt/file
> open("/mnt/file", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) =
> -1 EACCES (Permission denied)
> utimes("/mnt/file", NULL) = -1 EACCES (Permission denied)
> ...
> touch: cannot touch `/mnt/file': Permission denied
This is on a filesystem that has been mounted with the -ro flag? That
would be a client bug.
Hmm... The client code does look a bit dodgy there (particularly NFSv4).
I'll see if I can come up with a patch.
> If the file does not exist however, everything is ok:
> $ touch /mnt/file
> touch: cannot touch /mnt/file': Read-only file system
> $ strace -e trace=file touch /mnt/file
> open("/mnt/file", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) =
> -1 EROFS (Read-only file system)
> utimes("/mnt/file", NULL) = -1 ENOENT (No such file or directory)
>
>
> Which brings me right to question... should mountd or knfsd be adjusted to
> refuse a rw mount request if an nfs export is only available as ro? Like it is
> already the case with normal block devices:
How would knfsd or mountd know? There is no way for the client to
communicate to the server that it is mounting for read-write.
Cheers,
Trond
>> # mount localhost:/export /mnt -t nfs -oro
>
>This is on a filesystem that has been mounted with the -ro flag? That
>would be a client bug.
I seem to mix things up too often. Smaller and correct:
-o rw for ro-exported-fs returns EACCES instead of EROFS for write
operations on files that exist.
>Hmm... The client code does look a bit dodgy there (particularly NFSv4).
>I'll see if I can come up with a patch.
I use nfsv3...
>> Which brings me right to question... should mountd or knfsd be adjusted to
>> refuse a rw mount request if an nfs export is only available as ro? Like it is
>> already the case with normal block devices:
>
>How would knfsd or mountd know? There is no way for the client to
>communicate to the server that it is mounting for read-write.
What, the client does not pass the ro/rw flag along? Humm.
But knfsd knows that a certain export is ro, and therefore should return EROFS
for all write operations that it receives.
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
In message <[email protected]>, Jan Engelhardt writes:
> >How would knfsd or mountd know? There is no way for the client to
> >communicate to the server that it is mounting for read-write.
>
> What, the client does not pass the ro/rw flag along? Humm.
NFSv2/3 has no such flags I know of to pass during MOUNT.
> But knfsd knows that a certain export is ro, and therefore should return
> EROFS for all write operations that it receives.
That it probably should. It's more correct and consistent w/ what you get
from other file systems mounted ro.
IIRC, other servers (Solaris) _do_ return EROFS. The best way we can
convince linux-nfs to change this behavior is if the majority of other NFS
servers return EROFS.
> Jan Engelhardt
So it's not clear whether it's even possible for an NFS client to find out
that a server is exporting the f/s read-only.
Even if it were possible, I suspect that some people would still like the
current behavior for the following logic: some times sysadmins want to take
down a file server for a period of time, possibly for emergency maintenance,
and they don't want any nfs client-side user to write anything to that
server (which the client mounted). So they re-export the f/s as readonly.
Existing clients start getting all sorts of errors but they can't change the
state of the server's disk. In most cases where I've seen when this
happens, it's some sort of maintenance like replacing a failed disk in a
RAID array: you want the array to rebuild quickly, so you don't want to have
users write new files while it's rebuilding.
Erez.