Re: [Unionfs] Re: NFS Permission denied instead of EROFS

[Erez Zadok]

In message <Pine.LNX.4.61.0510280843340.6910@xxxxxxxxxxxxxxx>, 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/