All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Gemkow <ulrich.gemkow@ikr.uni-stuttgart.de>
To: nfs@lists.sourceforge.net
Subject: nfs-client 2.6.20 bizarre ro-mount
Date: Thu, 1 Mar 2007 16:25:48 +0100	[thread overview]
Message-ID: <200703011625.51457.ulrich.gemkow@ikr.uni-stuttgart.de> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1664 bytes --]

Hello,

I have a rather bizare problems with the nfs-client in
Linux 2.6.20, the previously used kernel 2.6.17 worked fine:

For one specific filesystem, which is exported rw, the client
mounts the filesystem (according to /proc/mounts) as ro 
despite the fact that the mount-command asks to mount
it rw.

When doing a "mount -o remount,rw ..." after the first mount
the filesystem is writable and all is fine (and /proc/mounts
shows the mountpoint as "rw").

To make things more interesting, when doing a second mount
after the rw-remount, the mount is writable. So it seems 
that the _first_ mount for the mountpoint fails.

The mountpoint is located in a ramdisc.

The problem does not happen with client kernel 2.6.17. The 
configuration besides the kernel is unchanged. It only happens
with one filesystem, other filesystems from the same server
are mounted rw as requested. For us it is always reproducible
for all our clients. I found nothing special for this problematic
filesystem.

Server kernel is Linux vanilla 2.6.17 (unchanged), distribution
is Fedora Core 6 for client and server.

I checked really careful that nothing else besides the kernel
changes in the systems and that there is no obvious "user error".

Has anyone a glue? The workaround is simple (remount) but I 
do not understand the changed behaviour.

Thanks in advance

-Ulrich

-- 
|-----------------------------------------------------------------------
| Ulrich Gemkow
| University of Stuttgart
| Institute of Communication Networks and Computer Engineering (IKR)
|-----------------------------------------------------------------------

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

                 reply	other threads:[~2007-03-01 15:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703011625.51457.ulrich.gemkow@ikr.uni-stuttgart.de \
    --to=ulrich.gemkow@ikr.uni-stuttgart.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.