On Mon, May 05, 2014 at 04:51:25PM +0200, Lukáš Czerner wrote:
> On Mon, 5 May 2014, Theodore Ts'o wrote:
> > What we would need to do is file a feature request in the other file
> > systems to save this information, and then add proper support for to
> > pass this information from the VFS layer into the struct
> > super_operations's mount function, which would be the proper, sane way
> > to provide this functionality.
> >
> > - Ted
>
> Which would be reasonable if there was a consumer of such
> information and it seemed to be useful. So I wonder what other
> people think about that.
>
> Karel, you had some suggestions about how to utilize that aside from
> the mkfs...
It's really simple to add another NAME=value to the low-level part of
the libblkid (used to feed udev db). The question is how usable will
that, I can imagine:
1) audit / logging purpose
2) mount <device> --last-target
3) automount (for example udisks and removable media)
unfortunately 2) and 3) seem fragile as the filesystem superblocks
have no clue about namespaces and the same filesystem is possible to
mount in the same time to more places, etc.
BTW, the current trend is to use GPT partition types to identify
purpose of the partition filesystem (for example extra GUID for
/home). It's FS independent solution and it allows use the right
filesystems for the right mountpoints. It's very attractive for
example for virtual images where you don't have to setup fstab and
identify FS, but you still have (for example) /home on the right
place.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
