Re: [REGRESSION] nfs client: Read-only file system (2.6.19-rc1,2)

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2006-10-18 at 17:46 +0200, Jiri Slaby wrote:
> Jiri Slaby wrote:
> > Do not remove CCs.
> > Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
> > Cc: Jiri Slaby <jirislaby@gmail.com>
> > 
> > Sven Hoexter wrote:
> >> Trond Myklebust wrote:
> >>> On Tue, 2006-10-17 at 17:24 +0200, Jiri Slaby wrote:
> >>
> >> Hi,
> >>
> >>>> I can't write on mounted nfs filesystem since 2.6.19-rc1 (nfs client):
> >>>> touch: cannot touch `aaa': Read-only file system
> >>>>
> >>>> strace says:
> >>>> open("aaa", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) 
> >>>> = -1
> >>>> EROFS (Read-only file system)
> >>>>
> >>>> 2.6.18 behaves correctly. Settings are the same, does anybody have any
> >>>> clue?
> >>> What does "cat /proc/mounts" say?
> >> Ok I'm not the OP but I can confirm the problem.
> >>
> >>> From /proc/mounts:
> >> arthur:/mnt/disk2/mp3 /mnt/mp3 nfs 
> >> ro,nosuid,nodev,noexec,vers=3,rsize=8192,wsize=8192,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=arthur 
> >> 0 0
> >>
> >> Reports ro here while mount still reports rw:
> >> arthur:/mnt/disk2/mp3 on /mnt/mp3 type nfs 
> >> (rw,noexec,nosuid,nodev,addr=192.168.88.80)
> > 
> > I will post my output in some hours, if still needed.
> 
> The very same thing. /etc/mtab still reports rw, while /proc/mounts says ro, weird.

I'll bet that you have always had a subdirectory of the exact same
filesystem mounted somewhere else ro, right?

The new NFS mount code will put those in the same superblock, and
whichever directory gets mounted first will determine whether or not the
superblock is marked as read-only.
Basically, NFS is now doing the exact same thing that local filesystems
have been doing all the time: if it is on the same disk, then it is all
represented by the same superblock. OTOH, if your server is exporting
more than one partition, then different partitions will be represented
by different superblocks.
We need to do this for the same reason that local filesystems do it: it
is the only way to ensure cache consistency. Otherwise, if you make
changes to a file that happens to be mounted in more than one place,
then you will see inconsistent results on the other mountpoints.

Per-mountpoint control over the 'ro' flag (i.e. to allow you to do
'mount --bind -oro /foo /bar') is a separate issue that needs further
work at the VFS level.

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/