xfs
[Top] [All Lists]

Re: [XFS-1.0.2,LVM-1.0.1,linux-2.4.14] "mount -U <uuid>" does not work w

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: [XFS-1.0.2,LVM-1.0.1,linux-2.4.14] "mount -U <uuid>" does not work with XFS.
From: karlheg@xxxxxxxxxxxxxx (Karl M. Hegbloom)
Date: 11 Dec 2001 13:24:43 -0800
Cc: Steve Lord <lord@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20011211090253.D70201@wobbly.melbourne.sgi.com>
References: <871yi6zq3z.fsf@juniper.intra.microsharp.com> <1007996560.27133.2.camel@jen.americas.sgi.com> <871yi3xbo4.fsf@juniper.intra.microsharp.com> <20011211090253.D70201@wobbly.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence)
>>>>> "Nathan" == Nathan Scott <nathans@xxxxxxx> writes:

    >> They used a fake "xfs_sb" struct, with dummy's in it for padding to
    >> try and get the right offsets for the uuid_t and the sb_fname[].  I
    >> think they (mount) got the offset correct for the uuid_t, but it
    >> looks to me like the offset of the label can vary depending on if
    >> you've built XFS with debugging or not, since there are inline
    >> xfs_inode_t's in there.  It would be nice if the label was higher in
    >> the struct, in this case.

    Nathan> We are talking about the XFS ondisk superblock here - its size
    Nathan> does not ever change and the offset of individual fields is always
    Nathan> the same, independent of the way XFS was built.

    Nathan> There are no inline xfs_inode_t's in the superblock, I'm not sure
    Nathan> what makes you think that?  (xfs_ino_t != xfs_inode_t -- is that it?
    Nathan> an xfs_ino_t is an inode number, this is always 64 bits long in XFS)

 I bet that's it.

    >> Perhaps there should be ioctl's for obtaining the UUID and filesystem
    >> label, given a file descriptor open on the block device?

    Nathan> The block device doesn't know where the UUID for the filesystem
    Nathan> would be (the block device doesn't even know what filesystem type
    Nathan> is being used above it).

 Oh, yeah.  That makes sense.  (I'm new.)

    >> Ok; it's a problem with LVM LV's and XFS; I just tested an XFS in a
    >> real x86 BIOS partition, and it worked fine with -U.

    Nathan> Maybe there is a misunderstanding as to which UUID you need to use
    Nathan> (LVM should have nothing to do with this).  You should be using the
    Nathan> UUID which is displayed by:

    Nathan> # xfs_db -r -c uuid /dev/XXX
    Nathan> uuid = cecbd95e-0c0f-46b6-9fd1-d024c3621692
    Nathan> # 

 Is that different from what I would get by using:

 # xfs_admin -u /dev/XXX

    Nathan> Please send your patch here if you still think its necessary - I
    Nathan> wrote the XFS-specific part of this util-linux code, tested it and
    Nathan> AFAICT it still works just fine.

 I wrote a patch that you can find in the Debian BTS under
 "util-linux" (bugs.debian.org).  It's not right though.  It doesn't
 work right when you run a "mount -a" and there are UUID mounts in
 fstab.  The reason is that it will keep scanning and find a
 filesystem UUID on the PV's, for filesystems already mounted as LV's.

 I suppose it needs to skip PV's (partitions) that are part of VG's?
 In other words, it must know the partition type.  I wonder why
 "/proc/partitions" does not display the type?  It does display the
 device major number though...

 I was rushed and must get on with other things.  I leave it to you
 and the other util-linux maintainers.

-- 
mailto: (Karl M. Hegbloom) karlheg@xxxxxxxxxxxxxx
http://www.microsharp.com
phone://USA/WA/360-260-2066
jabber: karlheg@xxxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>