Re: [PATCH v4] Add ioctls to get/set the ext4 superblock uuid.

On Wed, Jul 20, 2022 at 02:00:25PM -0400, Theodore Ts'o wrote:

On Wed, Jul 20, 2022 at 03:11:21PM +0100, Matthew Wilcox wrote:

quoted

Uhhh.  So what are the semantics of len?  That is, on SET, what does
a filesystem do if userspace says "Here's 8 bytes" but the filesystem
usually uses 16 bytes?  What does the same filesystem do if userspace
offers it 32 bytes?  If the answer is "returns -EINVAL", how does
userspace discover what size of volume ID is acceptable to a particular
filesystem?

And then, on GET, does 'len' just mean "here's the length of the buffer,
put however much will fit into it"?  Should filesystems update it to
inform userspace how much was transferred?

What I'd suggest is that for GET, the length field when called should
be the length of the buffer, and if the length is too small, we should
return some error --- probably EINVAL or ENOSPC.  If the buffer size
length is larger than what is needed, having the file system update it
with the size of the UUID that was returned.

And this would be how the userspace can discover size of the UUID.  In
practice, though, the human user is going to be suppliyng the UUID,
which means the *human* is going to have to understand that "oh, this
is a VFAT file system, so I need to give 32-bit UUID formatted as
DEAD-BEAF" or "oh, this is a ntfs file system, so I need to enter into
the command line a UUID formatted as the text string
A24E62F14E62BDA3".  (The user might also end up having to ntfs or vfat
specific uuid changing tool; that's unclear at this point.)

I think you covered all my questions there except for what happens
if the user tried to set ext4 to 0xDEADBEEF; that should return
-EINVAL?  They could specify 0xDEADBEEF'00000000'00000000'00000000 or
0x00000000'00000000'00000000'DEADBEEF, but it'd be up to them to choose
which one they wanted rather than have the filesystem pad it out for them?

As far as Jeremy's patch is concerned, I don't think we need to change
anything forthe SET ioctl, but for the GET util, it would be better in
the extremely unlikely case where the user pass in a length larger
than 16 bytes (say, 32), that we return the 16 byte UUID, and update
the length field to be 16 bytes.

I don't think it's strictly necessary, since in practice there is no
reason why a file system's volume identifier would ever be larger than
16 bytes --- the chances that we might need an extra 240 bytes to
specify a multiverse identifier seems.... unlikely.  :-)

Yes, 128 bits is sufficiently unique for this use case.