Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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
