Re: NFS and /dev/mdXpY

[Roger Heflin <rogerheflin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Wed, Apr 21, 2010 at 11:48 AM, Vlad Glagolev <stealth-L+UJwxqiw56VyaH7bEyXVA@public.gmane.org> wrote:
> Thanks for reply, Steve!
>
> parameters are pretty trivial, (rw,insecure) for exports, and defaults while mounting via ``mount host:/path /path'' command.
>
> Yes. That sounds interesting, since XFS works fine with there partitions.
> Also, I must say it's WD20EARS drives (with 4kb sector size, though parted says it's 512b).
>
> I also tried another NFS daemon implementation (cvs version, not .22) -- unfsd (unfs3).
> It mounts ok, but when I try to write any file to the server -- I get the same error (Stale NFS file handle).
>
> And on the server side in dmesg I see this:
>
> --
> NFS: server 172.17.2.2 error: fileid changed
> fsid 0:f: expected fileid 0x2033, got 0xb6d1e05fa150ce09
> NFS: server 172.17.2.2 error: fileid changed
> fsid 0:f: expected fileid 0x2033, got 0x26550b0132c0b1
> NFS: server 172.17.2.2 error: fileid changed
> fsid 0:f: expected fileid 0x2033, got 0x8202a60053000020
> NFS: server 172.17.2.2 error: fileid changed
> fsid 0:f: expected fileid 0x2033, got 0xe542f93ebc8fe157
> NFS: server 172.17.2.2 error: fileid changed
> fsid 0:f: expected fileid 0x2033, got 0xc00cd74ea904301
> --
>
> looks like NFS protocol doesn't like something in partitioned software RAID.
>


Try manually setting the fsid=something in the exports file and
reexport and remount on the target system, if there was a fsid
collision of some sort then nfs would be hitting the wrong fs...

NFS generates the fsid automatically based on the devices major minor,
and it is possible there is something odd about the major minor
numbers that make them not unique...and collide with someone else
major minor.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html