lkml.org 
[lkml]   [2020]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 05/19] vfs: Introduce a non-repeating system-unique superblock ID [ver #16]
Date
Darrick J. Wong <darrick.wong@oracle.com> wrote:

> Ahah, this is what the f_sb_id field is for. I noticed a few patches
> ago that it was in a header file but was never set.
>
> I'm losing track of which IDs do what...
>
> * f_fsid is that old int[2] thing that we used for statfs. It sucks but
> we can't remove it because it's been in statfs since the beginning of
> time.
>
> * f_fs_name is a string coming from s_type, which is the name of the fs
> (e.g. "XFS")?
>
> * f_fstype comes from s_magic, which (for XFS) is 0x58465342.
>
> * f_sb_id is basically an incore u64 cookie that one can use with the
> mount events thing that comes later in this patchset?
>
> * FSINFO_ATTR_VOLUME_ID comes from s_id, which tends to be the block
> device name (at least for local filesystems)
>
> * FSINFO_ATTR_VOLUME_UUID comes from s_uuid, which some filesystems fill
> in at mount time.
>
> * FSINFO_ATTR_VOLUME_NAME is ... left to individual filesystems to
> implement, and (AFAICT) can be the label that one uses for things
> like: "mount LABEL=foo /home" ?
>
> Assuming I got all of that right, can we please capture what all of
> these "IDs" mean in the documentation?

Basically, yes. Would it help if I:

(1) Put the ID generation into its own patch, first.

(2) Put the notification counter patches right after that.

(3) Renamed the fields a bit, say:

f_fsid -> fsid
f_fs_name -> filesystem_name
f_fstype -> filesystem_magic
f_sb_id -> superblock_id
f_dev_* -> backing_dev_*

David

\
 
 \ /
  Last update: 2020-02-20 13:46    [W:0.337 / U:1.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site