Re: NFS and /dev/mdXpY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 22 Apr 2010 15:56:21 -0400
Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote:

> On Thu, 2010-04-22 at 23:51 +0400, Vlad Glagolev wrote: 
> > On Thu, 22 Apr 2010 15:47:30 -0400
> > Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote:
> > 
> > > On Thu, 2010-04-22 at 15:32 -0400, J. Bruce Fields wrote: 
> > > > On Thu, Apr 22, 2010 at 10:53:10PM +0400, Vlad Glagolev wrote:
> > > > > On Thu, 22 Apr 2010 14:25:43 -0400
> > > > > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> > > > > 
> > > > > > On Sat, Apr 17, 2010 at 07:57:47PM +0400, Vlad Glagolev wrote:
> > > > > > > Well, hello there,
> > > > > > > 
> > > > > > > Posted it on linux-kernel ML also, and post it here, for more specific analysis.
> > > > > > > 
> > > > > > > I faced this problem today while trying to mount some NFS share on OpenBSD box.
> > > > > > > I mounted it successfully without any visible errors, but I wasn't able to cd there, the printed error was:
> > > > > > > 
> > > > > > > ksh: cd: /storage - Stale NFS file handle
> > > > > > > 
> > > > > > > Apropos, the partition is 5.5 TB. I tried another one on my box and it was mounted successfully. It was possible to manage files there too. Its size is ~3GB.
> > > > > > > That's why the first time I thought about some size limitations of OpenBSD/Linux/NFS.
> > > > > > > 
> > > > > > > While talking on #openbsd @ freenode, I discovered this via tcpdump on both sides:
> > > > > > > 
> > > > > > > http://pastebin.ca/1864713
> > > > > > > 
> > > > > > > Googling for 3 hours didn't help at all, some posts had similiar issue but either with no answer at all or without any full description.
> > > > > > > 
> > > > > > > Then I started to experiment with another Linux box to kill the possible different variants.
> > > > > > > 
> > > > > > > On another box I also have nfs-utils 1.1.6 and kernel 2.6.32. Mounting that big partition was unsuccessful, it got just stuck. On tcpdump I've seen this:
> > > > > > 
> > > > > > I'm a bit confused.  What kernel and nfs-utils version is running on the
> > > > > > problematic Linux server?
> > > > > 
> > > > > same. nfs-utils 1.1.6 and kernel 2.6.32.
> > > > 
> > > > Huh.  That should be new enough for it to be using uuid's.  I wonder why
> > > > it isn't?
> > > 
> > > What are the contents of /dev/disk/by-uuid?
> > > 
> > 
> > $ ls -1 /dev/disk/by-uuid/
> > 0e9742f6-44e3-431c-911f-4c914e4f81d5
> > 31ae89c6-dba6-4351-b3a9-e8b08be07c3d
> > 4429ba7a-afd2-4c61-83a0-900dae1bccdc
> > 463bbc42-c19b-4b9e-bae7-838ac0e2e5c6
> > 473b9320-88a4-44eb-b592-2ac98619bc9b
> > 53d16b07-d496-4f8f-ad59-ea34aaf169f4
> > 6adf1c55-405c-43cf-a84d-be5d2746d300
> > b35a7bca-12ad-4738-a895-52f20b7cc5d9
> > dc892f1f-0b83-41dd-bde7-0761295f33a3
> > f7ac4165-320f-4235-a78a-5fe1bd0aac24
> > 
> 
> So, when you do 'ls -l' on the above, you do indeed see all the
> partitions that are being exported via NFS?

there's only one, and yes, you're right.. /dev/md2p6 isn't in the list.

According to blkid:

# blkid
/dev/sda1: UUID="9a9beac0-d5fa-94d1-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sda2: UUID="8327bc1c-3d13-ee78-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sda3: UUID="01821f8d-da8e-fd6a-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdb1: UUID="9a9beac0-d5fa-94d1-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdb2: UUID="8327bc1c-3d13-ee78-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdb3: UUID="01821f8d-da8e-fd6a-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdc1: UUID="ed9c6039-5faf-d0ef-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdc2: UUID="8327bc1c-3d13-ee78-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdc3: UUID="01821f8d-da8e-fd6a-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdd1: UUID="ed9c6039-5faf-d0ef-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdd2: UUID="8327bc1c-3d13-ee78-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/sdd3: UUID="01821f8d-da8e-fd6a-86df-b710391e5a7c" TYPE="linux_raid_member" 
/dev/md0: UUID="53d16b07-d496-4f8f-ad59-ea34aaf169f4" TYPE="xfs" 
/dev/md2p1: UUID="31ae89c6-dba6-4351-b3a9-e8b08be07c3d" TYPE="swap" 
/dev/md2p2: UUID="dc892f1f-0b83-41dd-bde7-0761295f33a3" TYPE="xfs" 
/dev/md2p3: UUID="f7ac4165-320f-4235-a78a-5fe1bd0aac24" TYPE="xfs" 
/dev/md2p4: UUID="4429ba7a-afd2-4c61-83a0-900dae1bccdc" TYPE="xfs" 
/dev/md2p5: UUID="b35a7bca-12ad-4738-a895-52f20b7cc5d9" TYPE="xfs" 
/dev/md2p6: UUID="9f8d66e8-4b11-4ae7-8f90-b00ee9d204b1" TYPE="xfs" 
/dev/md1: UUID="0e9742f6-44e3-431c-911f-4c914e4f81d5" TYPE="xfs" 
/dev/md3: UUID="463bbc42-c19b-4b9e-bae7-838ac0e2e5c6" TYPE="xfs" 
/dev/sde1: UUID="6adf1c55-405c-43cf-a84d-be5d2746d300" TYPE="ext2"

and not all of them exist at /dev/disk/by-uuid:

# ls -1 /dev/disk/by-uuid
0e9742f6-44e3-431c-911f-4c914e4f81d5 <- /dev/md1
31ae89c6-dba6-4351-b3a9-e8b08be07c3d <- /dev/md2p1
4429ba7a-afd2-4c61-83a0-900dae1bccdc <- /dev/md2p4
463bbc42-c19b-4b9e-bae7-838ac0e2e5c6 <- /dev/md3
473b9320-88a4-44eb-b592-2ac98619bc9b <- ??
53d16b07-d496-4f8f-ad59-ea34aaf169f4 <- /dev/md0
6adf1c55-405c-43cf-a84d-be5d2746d300 <- /dev/sde1
b35a7bca-12ad-4738-a895-52f20b7cc5d9 <- /dev/md2p5
dc892f1f-0b83-41dd-bde7-0761295f33a3 <- /dev/md2p2
f7ac4165-320f-4235-a78a-5fe1bd0aac24 <- /dev/md2p3

Interesting. so 9f8d66e8-4b11-4ae7-8f90-b00ee9d204b1 != 473b9320-88a4-44eb-b592-2ac98619bc9b.

Bug in udev?

-- 
Dont wait to die to find paradise...
--
Cheerz,
Vlad "Stealth" Glagolev

Attachment: pgpr7OB1nWsow.pgp
Description: PGP signature


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux