Skip to contentSkip to conversation

NFS export broke with change from ext3 to xfs

DISCUSSION Krzysztof Adamski 4 participants 6 messages Jan 5, 2010 – Jan 6, 2010

lore
Share & tools
lore

Krzysztof Adamski

author
#0 lore raw

Hi All,

I just changed one filesystem on my mythbox from ext3 to xfs, and now I can't get a client machine to NFS mount from it.

This is the export file on the server:
/file-store/nfs-roots/f1/home
f1(rw,no_root_squash,sync,no_subtree_check)
/file-store/nfs-roots/f1/usr
f1(rw,no_root_squash,sync,no_subtree_check)
/file-store/nfs-roots/f1/var
f1(rw,no_root_squash,sync,no_subtree_check)

and on the client(f1) the three filesystems are mount on /home, /usr, and /var

This worked fine when /file-store on the server was formatted with ext3, now that it is formatted with xfs I get this message on the client:
mount.nfs: Stale NFS file handle
I get this message 3 times.
Nothing else changed, both systems are Debian Lenny with custom kernel. Server is 2.6.28, client is 2.6.29.6. NFS is version 3.
The fstab on the server has this:
/dev/mapper/big--raid-file--store /file-store xfs
noatime,logbsize=256k,inode64 0 1

The reason for the change of the filesystem was an upgrade of the drives in the RAID, now the filesystem is 7T instead of 2.4T, nothing else was changed. Why did this work with ext3 and does not with XFS? What can I do to get this to work, short of reverting to ext3?

K

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw
Quoted 12 lines · Krzysztof Adamski

Hi All,

I just changed one filesystem on my mythbox from ext3 to xfs, and now I can't get a client machine to NFS mount from it.

This is the export file on the server:
/file-store/nfs-roots/f1/home f1(rw,no_root_squash,sync,no_subtree_check)
/file-store/nfs-roots/f1/usr
f1(rw,no_root_squash,sync,no_subtree_check)
/file-store/nfs-roots/f1/var
f1(rw,no_root_squash,sync,no_subtree_check)

Quoted 7 lines

and on the client(f1) the three filesystems are mount on /home, /usr, and /var

This worked fine when /file-store on the server was formatted with ext3, now that it is formatted with xfs I get this message on the client:
mount.nfs: Stale NFS file handle
I get this message 3 times.

I dunno, this should work. Anything in either of the system logs?

-Eric

Quoted 6 lines

Nothing else changed, both systems are Debian Lenny with custom kernel. Server is 2.6.28, client is 2.6.29.6. NFS is version 3.
The fstab on the server has this:
/dev/mapper/big--raid-file--store /file-store xfs
noatime,logbsize=256k,inode64 0 1

Quoted 7 lines

The reason for the change of the filesystem was an upgrade of the drives in the RAID, now the filesystem is 7T instead of 2.4T, nothing else was changed. Why did this work with ext3 and does not with XFS? What can I do to get this to work, short of reverting to ext3?

K

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

author
#2 lore raw
Quoted 17 lines
Quoted 16 lines · Krzysztof Adamski

Hi All,

I just changed one filesystem on my mythbox from ext3 to xfs, and now I can't get a client machine to NFS mount from it.

This is the export file on the server:
/file-store/nfs-roots/f1/home
f1(rw,no_root_squash,sync,no_subtree_check)
/file-store/nfs-roots/f1/usr
f1(rw,no_root_squash,sync,no_subtree_check)
/file-store/nfs-roots/f1/var
f1(rw,no_root_squash,sync,no_subtree_check)

and on the client(f1) the three filesystems are mount on /home, /usr, and /var

Quoted 6 lines
Quoted 4 lines

This worked fine when /file-store on the server was formatted with ext3, now that it is formatted with xfs I get this message on the client:
mount.nfs: Stale NFS file handle
I get this message 3 times.

I dunno, this should work. Anything in either of the system logs?

On the server:

Jan  4 19:27:03 Myth mountd[5342]: authenticated mount request from
x.x.x.x:741 for /file-store/nfs-roots/f1/var
(/file-store/nfs-roots/f1/var)
Jan  4 19:27:03 Myth mountd[5342]: authenticated mount request from
x.x.x.x:757 for /file-store/nfs-roots/f1/usr
(/file-store/nfs-roots/f1/usr)
Jan  4 19:27:03 Myth mountd[5342]: authenticated mount request from

x.x.x.x:759 for /file-store/nfs-roots/f1/home
(/file-store/nfs-roots/f1/home)
but this is identical to when it worked.
No logs on the client, /var is not yet mounted.

Should I be asking on the NFS list?

Quoted 16 lines

-Eric

Quoted 13 lines

Nothing else changed, both systems are Debian Lenny with custom kernel. Server is 2.6.28, client is 2.6.29.6. NFS is version 3.
The fstab on the server has this:
/dev/mapper/big--raid-file--store /file-store xfs
noatime,logbsize=256k,inode64 0 1

The reason for the change of the filesystem was an upgrade of the drives in the RAID, now the filesystem is 7T instead of 2.4T, nothing else was changed. Why did this work with ext3 and does not with XFS? What can I do to get this to work, short of reverting to ext3?

K

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#4 lore raw

Le Tue, 5 Jan 2010 12:43:32 -0500 vous écriviez:

Quoted 4 lines

Remove the inode64 mount option or move every export to a separate filesystem. The NFS code can't cope with 64 bit inode numbers when exporting a subtree of a filesystem. You'd see the same issue with e.g. ocfs2 or gfs2.

Does the kernel architecture (32 or 64 bits) have any influence there?

Signature · 11 lines
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<[email protected]>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#5 lore raw
Quoted 8 lines · Emmanuel Florac

Le Tue, 5 Jan 2010 12:43:32 -0500 vous ?criviez:

Quoted 4 lines

Remove the inode64 mount option or move every export to a separate filesystem. The NFS code can't cope with 64 bit inode numbers when exporting a subtree of a filesystem. You'd see the same issue with e.g. ocfs2 or gfs2.

Does the kernel architecture (32 or 64 bits) have any influence there?

Unfortunately not. But if you specify a uuid in the /etc/exports file it should use a different filesystem handle format that has space for 8 byte inode numbers. I'm not entirely sure how nfsutils selects them - it's been a while since I dealt with that code.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs