Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 174385

Summary:	Exporting Veritas VxFS via NFS seems not work
Product:	Red Hat Enterprise Linux 4	Reporter:	Urs J. Schürer <urs>
Component:	kernel	Assignee:	Steve Dickson <steved>
Status:	CLOSED DUPLICATE	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jbaron
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-07-20 10:51:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Urs J. Schürer 2005-11-28 18:22:15 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

Description of problem:
When trying to export a Veritas Filesystem (SF 4.1.00) via NFS
on a 32Bit i386 kernel, mounting works fine (MOUNTD) but
nfsd does not answer at all. Exporting other filesystem
types like ext3, reiserfs and so on works as expected.
This might be a VxFS problem and not a knfsd one since the
same problem seems to exist in Suse SLES 9.0.
Further analysis of the problem seems to be difficult.
Enabling nfsd debugging up to 0x7fff did reveal:


Nov 28 18:23:54 veritas kernel: nfsd: FSINFO(3)   12: 00030001 0ff0c7fe 00000002 00000000 00000000 00000000
Nov 28 18:23:54 veritas kernel: nfsd: fh_verify(12: 00030001 0ff0c7fe 00000002 00000000 00000000 00000000)
Nov 28 18:23:54 veritas kernel: Want update, refage=120, age=0
Nov 28 18:23:54 veritas kernel: exp_find_key: cache_check failed: -11
Nov 28 18:23:54 veritas kernel: nfsd: fh_verify failed: nfserr_dropit
Nov 28 18:23:54 veritas kernel: nfsd: Dropping request due to malloc failure!


Although after reading nfsfh.c I doubt very much its a malloc problem here.
Just if it might be helpfull some more debug output:


Nov 28 18:23:50 veritas rpc.mountd: authenticated mount request from fidji.sitb.de:877 for /testvol (/testvol)
Nov 28 18:23:50 veritas kernel: svc: socket e0e04080 served by daemon c16e3600
Nov 28 18:23:50 veritas kernel: svc: got len=0
Nov 28 18:23:50 veritas kernel: svc: socket e0e04080 busy, not enqueued
Nov 28 18:23:50 veritas kernel: svc: server c16e2200 waiting for data (to = 3600000)
Nov 28 18:23:50 veritas kernel: svc: server c16e3a00, socket d4bd6080, inuse=1
Nov 28 18:23:50 veritas kernel: svc: tcp_recv d4bd6080 data 1 conn 0 close 0
Nov 28 18:23:50 veritas kernel: svc: socket d4bd6080 recvfrom(d4bd60f0, 0) = 4
Nov 28 18:23:50 veritas kernel: svc: TCP record, 40 bytes
Nov 28 18:23:50 veritas kernel: svc: socket d4bd6080 recvfrom(d4bca028, 4056) = 40
Nov 28 18:23:50 veritas kernel: svc: TCP complete record (40 bytes)
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 served by daemon c16e2200
Nov 28 18:23:50 veritas kernel: svc: got len=40
Nov 28 18:23:50 veritas kernel: svc: svc_authenticate (0)
Nov 28 18:23:50 veritas kernel: svc: svc_authenticate: accept 0xe91186fe: status 5
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued
Nov 28 18:23:50 veritas kernel: svc: calling dispatcher
Nov 28 18:23:50 veritas kernel: nfsd_dispatch: vers 3 proc 0
Nov 28 18:23:50 veritas kernel: svc: socket d4bd6080 sendto([d4bcc000 28... ], 28) = 28 (addr 420d1fac)
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued
Nov 28 18:23:50 veritas kernel: svc: server c16e3a00 waiting for data (to = 3600000)
Nov 28 18:23:50 veritas kernel: svc: server c16e3600, socket d4bd6380, inuse=1
Nov 28 18:23:50 veritas kernel: svc: tcp_recv d4bd6380 data 0 conn 1 close 0
Nov 28 18:23:50 veritas kernel: svc: tcp_accept d4bd6380 sock d440dd80
Nov 28 18:23:50 veritas kernel: svc: tcp_accept e7784580 allocated
Nov 28 18:23:50 veritas kernel: svc: got len=0
Nov 28 18:23:50 veritas kernel: svc: server c16e3600 waiting for data (to = 3600000)
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 TCP (connected) state change 8 (svsk d4bd6080)
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 TCP data ready (svsk d4bd6080)
Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued
Nov 28 18:23:50 veritas kernel: svc: server c16e2200, socket d4bd6080, inuse=1
Nov 28 18:23:50 veritas kernel: svc: tcp_recv d4bd6080 data 1 conn 0 close 1
Nov 28 18:23:50 veritas kernel: svc: svc_delete_socket(d4bd6080)
Nov 28 18:23:50 veritas kernel: svc: server socket destroy delayed
Nov 28 18:23:50 veritas kernel: svc: got len=0
Nov 28 18:23:50 veritas kernel: svc: releasing dead socket
Nov 28 18:23:50 veritas kernel: svc: server c16e2200 waiting for data (to = 3600000)
Nov 28 18:23:50 veritas kernel: nfsd: exp_rootfh(/testvol [e2497588] *:VxVM65534/2)
Nov 28 18:23:50 veritas kernel: nfsd: fh_compose(exp c7:fffe/2 ///, ino=2)


Version-Release number of selected component (if applicable):
kernel-2.6.9-22.EL, SF 4.1.00.10-GA_RHEL4

How reproducible:
Always

Steps to Reproduce:
1. Install Veritas Storage Foundation 4.1.00
2. Create a VxVM Volume and export it via NFS
3. Try to mount this volume from a remote machine
  

Actual Results:  nfsd did not answer to FSINFO call, client retransmits call over and over

Expected Results:  nfsd should answer FSINFO and all other calls or at least should
drop an error back to the client.

Additional info:

What has been the clue behind http://support.veritas.com/docs/243789 ?

Comment 1 Urs J. Schürer 2005-11-30 15:17:49 UTC

Solution (thanks to Miguel from Veritas/Symantec Support):

This is basicaly a duplicate of #143897 and a documentation problem. Deep down
in the SF 4.1 Release Notes there is something about:

NFS Cannot Handle Minor Numbers Greater Than 255
>
> The NFS implementation in Linux does not support minor numbers greater
> than 255 (see the description of Red HAT Bugzilla Bug 143897 or SUSE
> Bugzilla Bug 49552 for details). As a result, volume devices with large
> minor numbers cannot be remotely mounted via NFS. The workaround is to
> use the vxdg command to change the base minor number of the disk group
> that contains the volumes.

Which I red (of course). What this note does not state is, that VxVM uses 
high minor numbers by default. So mine was 65534:

[root@veritas ~]# ls -l /dev/vx/dsk/testdg/testvol 
brw-------  1 root root 199, 65534 Nov 28 15:12 /dev/vx/dsk/testdg/testvol

doing:

[root@veritas ~]# umount /testvol
[root@veritas ~]# vxdg -g testdg reminor 100
[root@veritas ~]# ls -l /dev/vx/dsk/testdg/
total 0
brw-------  1 root root 199, 100 Nov 30 16:05 testvol
[root@veritas ~]# mount /testvol

resolved the problem:

[root@fidji ~]# df -k /mnt/t
Filesystem           1K-blocks      Used Available Use% Mounted on
veritas:/testvol      12582912     95008  12172608   1% /mnt/t


So this needs to be stated more clearly in the Release Notes. And maybe this
limitation should be removed from knfsd, or at least the error messages should
be changed to reveal a clear clue of the underlying problem.

Comment 2 Jeff Layton 2007-07-20 10:51:12 UTC


*** This bug has been marked as a duplicate of 143897 ***