On Thu, Nov 21, 2024 at 11:44:14AM +0100, Karel Zak wrote:
> I doubt it will be helpful for us.
>
> I believe that EXT4_IOC_GET_SUPERBLOCK will be used with a mountpoint
> file descriptor, but libblkid works directly with the block device
> (e.g. open(/dev/sda1)) where it searches for valid filesystems.
Yeah, that's why I haven't prioritized implementing it. Higher
priority is to implement ioctls so that tune2fs will no longer need to
modify the superblock while the file system is mounted, so we can
allow prohibiting read/write access to the block device while it is
mounted. (Well, after waiting a decent interval so that distros
everywhere can update to a sufficiently new version of e2fsprogs.)
I had guessed that libblkid wouldn't be excited about trying to
determine the mountpoint and using an ioctl that required an open fd
on the mountpoint, but if I had been wrong, I would have been happy to
priotize EXT4_IOC_GET_SUPERBLOCK higher on my todo list.
> Another issue is that libblkid does not check if the device is
> mounted, so the FS prober can be triggered in all cases. It simply
> calls seek()+read() and tries to be smart.
Well, what I had been proposing was something that could be used in
by the ext[234] specific probe code.
> Ideally, we would have a generic ioctl (for block devices) to ask the
> kernel if a superblock at a specific location is valid.
>
> ioctl(fd, BLKVERIFYFS, { .fsname="ext4", .offset=123456 })
I wouldn't have thought this to be that useful since there are plenty
of file systems known by libblkid that the kernel doesn't support ---
and even if the source code exists in the kernel, there is no
guarantee that it is actually compiled into a particular kernel image.
(Exhibit 1: Reiserfs)
So would it really simplify libblkid all that much?
Cheers,
- Ted
