Re: NFS hard read-only mount option - again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 28 Apr 2010 16:07:46 -0400
Valerie Aurora <vaurora@xxxxxxxxxx> wrote:

> 
> What I need can be summarized in the distinction between the following
> scenarios:
> 
> Scenario A: The NFS server reboots while a client has the file system
> mounted as the r/o layer of a union mount.  The server does not change
> the exported file system at all and re-exports it as hard read-only.
> This should work.
> 

Nitpick: This should be fine regardless of how it's exported. You
don't want the clients going bonkers just because someone pulled the
plug on the server accidentally. NFS was designed such that clients
really shouldn't be affected when the server reboots (aside from
stalling out on RPC calls while the server comes back up).

> Scenario B: The NFS server reboots as in the above scenario, but
> performs "touch /exports/client_root/a_file" before re-exporting the
> file system as hard read-only.  This is _not_ okay and in some form
> will cause a panic on the client if the client doesn't detect it and
> stop accessing the mount.
> 
> How to tell the difference between scenarios A and B?
> 

I don't believe you can, at least not with standard NFS protocols. I
think the best you can do is detect these problems on an as-needed
basis. Anything that relies on server behavior won't be very robust.

In the above case, the mtime on /exports/client_root will (likely) have
changed. At that point you can try to handle the situation without
oopsing.

There are quite a few ways to screw up your NFS server too that don't
involve changing the underlying fs. Suppose the server is clustered and
someone screws up the fsid's such that you get ESTALE's when you try to
access the root inode?

It would be best if union mounts could cope with that sort of problem
without oopsing (even if the alternative is EIO's for everything that
touches it).

-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux