Bug 426458 - nfs server RO, but client will not get error on write?
Summary: nfs server RO, but client will not get error on write?
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.4
Hardware: i386
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Ric Wheeler
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-21 08:25 UTC by Rafal Wijata
Modified: 2010-03-16 18:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-16 18:32:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rafal Wijata 2007-12-21 08:25:50 UTC
Description of problem:
I did this experiment, where one server exported filesystem via
nfs(ro,sync,no_root_squash), and the second mounted it with
mount -t nfs -o nfsvers=3 beta50:/mnt/mnt tmp
resulted mount is
server:/mnt/mnt /mnt/tmp nfs
rw,v3,rsize=32768,wsize=32768,hard,tcp,lock,addr=server 0 0

Next, I wrote very simple client, which opens nfs file in O_APPEND|O_SYNC mode,
and writes 1 byte in a infinite loop.

While the client application runs I did following tests on server
mount -o remount,ro /mnt/mnt
the server filesystem remounted RO fine, the file written by client stopped
growing, hence client haven't got any error to write() syscalls? It was writing
forever. I verified it with strace as well.

Next, instead of remounting it RO on the server, I changed the /etc/export line
to RO mode and restarted nfs service. The result was similar, file stopped
growing, the client stalled for a while, then again, it was not getting any
errors to the write() syscalls.

Is it bug, or nfs "mis" feature?

Version-Release number of selected component (if applicable):
kernel 2.6.9-42.0.10.ELsmp
nfs-utils-1.0.6-70.EL4

Actual results:
no write() error

Expected results:
error "RO filesystem" so client will not be lied, that the operation succeeded.

Comment 1 Peter Staubach 2008-06-18 15:44:09 UTC
Would you mind trying your "test" in a kernel newer than 2.6.9-56, please?

Comment 2 Rafal Wijata 2008-06-19 06:59:32 UTC
Well, this bug applies to RHEL4, and since I'm running RHEL4, i'd rather leave
thay testing to someone who's actually running rhel5.
BTW, there's a mistake in my first posting

< I did this experiment, where one server exported filesystem via
< nfs(ro,sync,no_root_squash), and the second mounted it with
> I did this experiment, where one server exported filesystem via
> nfs(rw,sync,no_root_squash), and the second mounted it with

Comment 3 Peter Staubach 2008-06-19 11:40:29 UTC
2.6.9-56 or newer kernels _are_ RHEL-4 kernels.

RHEL-5 is based on 2.6.18.

Please test using a RHEL-4 kernel at least as new as 2.6.9-56.

Comment 4 Rafal Wijata 2008-07-30 08:58:15 UTC
I really cannot. I was bound to rhel4.4/32bit, now I'm running rhel5.1/64bit

Comment 5 Peter Staubach 2008-07-30 12:15:48 UTC
Do you see this problem on your current system?

Comment 6 Rafal Wijata 2008-07-30 12:28:56 UTC
Haven't tested.
It's not like I experienced some problems cause this bug - It just showed during
tests.

I suppose You guys should have two machines to perform the test on various
environments.


Note You need to log in before you can comment on or make changes to this bug.