[Top] [All Lists]

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

To: "Karl M. Hegbloom" <karlheg@xxxxxxxxxxxxxx>
Subject: Re: [XFS-1.0.2,LVM-1.0.1,linux-2.4.14] "mount -U <uuid>" does not work with XFS.
From: Nathan Scott <nathans@xxxxxxx>
Date: Tue, 11 Dec 2001 09:02:54 +1100
Cc: Steve Lord <lord@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <871yi3xbo4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>; from karlheg@xxxxxxxxxxxxxx on Mon, Dec 10, 2001 at 09:39:56AM -0800
References: <871yi6zq3z.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1007996560.27133.2.camel@xxxxxxxxxxxxxxxxxxxx> <871yi3xbo4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i

On Mon, Dec 10, 2001 at 09:39:56AM -0800, Karl M. Hegbloom wrote:
> >>>>> "Steve" == Steve Lord <lord@xxxxxxx> writes:
>     Steve> Since the mount by uuid code is in the mount command, it is 
> possible
>     Steve> you do not have a recent enough mount command there. Check for XFS
>     Steve> specific code in the mount source.
>  I will look and see...  I would assume that since the man page
>  mentions XFS explicitly wrt UUID= mounting, that it is a recent
>  enough version.

Yes, you have a recent enough version.  This looks like the same
version that I am using too.

>  <time passes while karlheg greps code ...>
> mount/mount_by_label.c:
> 8<----------------------------------------------------------------->8
> /* for now, only ext2, ext3 and xfs are supported */
> static int
> get_label_uuid(const char *device, char **label, char *uuid) {
> 8<----------------------------------------------------------------->8
>  Well, it's _supposed_ to work...  But does not.

It works for me.

>  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.

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

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

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

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

>  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.

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

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

So, your fstab entry for this filesystem would be:
UUID=cecbd95e-0c0f-46b6-9fd1-d024c3621692 /mount xfs defaults 0 0

Or something to that effect - it shouldn't matter whether /dev/XXX
is a partition, a disk, or an md/lvm/... device.

>  Apparently the offset to the sb_fname is correct also; I tested a
>  "mount -L" with the same partition, and it works fine.  (but not on
>  an LVM LV.)

I guess what would be nice is a mount(8) option for displaying
the UUIDs (-u?) - along the lines of "mount -l" for filesystem
labels - this would probably make things much clearer.

>  I will report the bug against "util-linux", perhaps with a patch,
>  since I'm now looking at the peice of code that is likely causing the
>  problem.  (There's a big comment right there also.)

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

Hope this helps.



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