Re: [PATCH 3/3] ext4: Add support for FS_IOC_GETFSSYSFSPATH

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/15/24, 09:51, "Kent Overstreet" <kent.overstreet@xxxxxxxxx <mailto:kent.overstreet@xxxxxxxxx>> wrote:
> On Fri, Mar 15, 2024 at 12:45:50PM -0400, Theodore Ts'o wrote:
> > On Thu, Mar 14, 2024 at 11:53:02PM -0400, Kent Overstreet wrote:
> > > the new sysfs path ioctl lets us get the /sys/fs/ path for a given
> > > filesystem in a fs agnostic way, potentially nudging us towards
> > > standarizing some of our reporting.
> > >
> > > --- a/fs/ext4/super.c
> > > +++ b/fs/ext4/super.c
> > > @@ -5346,6 +5346,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
> > > sb->s_quota_types = QTYPE_MASK_USR | QTYPE_MASK_GRP | QTYPE_MASK_PRJ;
> > > #endif
> > > super_set_uuid(sb, es->s_uuid, sizeof(es->s_uuid));
> > > + super_set_sysfs_name_bdev(sb);
> >
> > Should we perhaps be hoisting this call up to the VFS layer, so that
> > all file systems would benefit?
>
>
> I did as much hoisting as I could. For some filesystems (single device
> filesystems) the sysfs name is the block device, for the multi device
> filesystems I've looked at it's the UUID.

Why not use the fs UUID for all cases, single device and multi device?
-- 
Oleg Kiselev 








[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux