On 2018年01月18日 13:27, Ilan Schwarts wrote: > Is there a way to retrieve this anonymous device number ?
No. Because returning device number on stat() call is already a stupid idea for any fs without consistent single device. For btrfs, it's because btrfs has multiple device and even for single device btrfs such bdev can change on-the-fly. This also applies to NFS, which also returns anonymous device number for stat. > And in addition, i assume that every device, will have device number, Yes, every device has its device number. "ls -l /dev/sd*" will show you device number. > and 2 devices on the OS can never have the same number. Even if they are > on different filesystem, this is since they are managed by the btrfs module. I have already said that, btrfs is using anonymous device number, which has no *physical* device for them, and device numbers of them are just guaranteed not to conflict with any possible real device. And for the reason why same btrfs mounted to different location have different device number returned, that's simple. Because they are different mount, where different VFS super_block is allocated and so is s_dev. Thanks, Qu > > On Jan 18, 2018 07:12, "Qu Wenruo" <quwenruo.bt...@gmx.com > <mailto:quwenruo.bt...@gmx.com>> wrote: > > > > On 2018年01月17日 22:36, Ilan Schwarts wrote: > > Hi, > > A new questions for this thread. Thanks in advance. > > > > Given a result from stat: > > builder@SLES12X86-64:~> stat /home/builder/myfile1 > > File: ‘/home/builder/myfile1’ > > Size: 0 Blocks: 0 IO Block: 4096 > regular empty file > > Device: 31h/49d Inode: 549453 Links: 1 > > > > I understand Device: 31h/49d is the physical device id ? > > > > Executing mount -v: > > /dev/sda2 on /srv type btrfs (rw,relatime,space_cache) > > /dev/sda2 on /opt type btrfs (rw,relatime,space_cache) > > /dev/sda2 on /home type btrfs (rw,relatime,space_cache) > > > > If i stat one of the mountpoints: > > > > builder@SLES12X86-64:~> stat /opt > > File: ‘/opt’ > > Size: 120 Blocks: 0 IO Block: 4096 directory > > Device: 30h/48d Inode: 256 Links: 1 > > Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ > root) > > Access: 2018-01-17 16:28:18.141305151 +0200 > > Modify: 2018-01-17 16:28:29.245304578 +0200 > > Change: 2018-01-17 16:28:29.245304578 +0200 > > Birth: - > > builder@SLES12X86-64:~> stat /home > > File: ‘/home’ > > Size: 48 Blocks: 0 IO Block: 4096 directory > > Device: 31h/49d Inode: 256 Links: 1 > > > > > > There are different devices (31h/49d, 30h/48d ), but it is still > /dev/sda2. > > As I already said (more than once), btrfs is a multi-device filesystem, > so its device number is mostly meaningless. > > The device number is just a meaningless (anonymous) one. > > Check btrfs_set_super() to see how it set its super_block->s_dev. > > > > > > > Additional question, 31h/49d, is returned from stat command, when > > looking at btrfs source code, stat uses function btrfs_getattr, i see > > they call: > > static int btrfs_getattr(struct vfsmount *mnt, > > struct dentry *dentry, struct kstat *stat) > > ... > > stat->dev = BTRFS_I(inode)->root->anon_dev; > > .. > > > > When printing from kernel BTRFS_I(inode)->root->anon_dev - I receive > > the number 2. and not 31h/49d. > > Just as its name, it's *anonymous* device, where no device should have > such device number. > > And as you already checked btrfs_getattr(), why not check a step futher > about generic_fillattr()? > > ------ > /** > * generic_fillattr - Fill in the basic attributes from the inode struct > * @inode: Inode to use as the source > * @stat: Where to fill in the attributes > * > * Fill in the basic attributes in the kstat structure from data that's > to be > * found on the VFS inode structure. This is the default if no getattr > inode > * operation is supplied. > */ > void generic_fillattr(struct inode *inode, struct kstat *stat) > { > stat->dev = inode->i_sb->s_dev; > stat->ino = inode->i_ino; > ------ > > device number is just get from superblock, and any device number > returned by fs-specific getattr function is overwritten. > > And BTW, root->anon_dev is also just another anonymous device number, > set by btrfs_init_fs_root() in fs/btrfs/disk-io.c: > ------ > ret = get_anon_bdev(&root->anon_dev); > if (ret) > goto fail; > ------ > > Thanks, > Qu > > > > > On Mon, Jan 15, 2018 at 2:13 PM, Qu Wenruo <quwenruo.bt...@gmx.com > <mailto:quwenruo.bt...@gmx.com>> wrote: > >> > >> > >> On 2018年01月15日 20:08, Ilan Schwarts wrote: > >>> Thanks for detailed information ! > >>> Its a legacy code for kernel module i maintain.. dont talk to me > about > >>> ancient when i need to maintain it to systems like solaris 8 or > RHEL4 > >>> 2.6.9 :( > >> > >> Well, that's unfortunate, I mean real unforunate... > >> > >> Despite that, if sticking to device number (dev_t), I think the > one in > >> super_block->s_dev won't help much. > >> Especially it can change when btrfs tries to add/delete devices. > >> > >> So it will be a very hard time for you to trace device number for > btrfs. > >> > >> Thanks, > >> Qu > >> > >>> > >>> > >>> > >>> On Mon, Jan 15, 2018 at 12:01 PM, Qu Wenruo > <quwenruo.bt...@gmx.com <mailto:quwenruo.bt...@gmx.com>> wrote: > >>>> > >>>> > >>>> On 2018年01月15日 17:24, Ilan Schwarts wrote: > >>>>> Qu, > >>>>> Given inode, i get the fsid via: inode->i_sb->s_dev; > >>>>> this return dev_t and not u8/u16 > >>>> > >>>> That's just a device number. > >>>> > >>>> Not really useful in btrfs, since btrfs is a multi-device > filesystem. > >>>> > >>>> Thanks, > >>>> Qu > >>>> > >>>>> > >>>>> > >>>>> On Sun, Jan 14, 2018 at 12:44 PM, Qu Wenruo > <quwenruo.bt...@gmx.com <mailto:quwenruo.bt...@gmx.com>> wrote: > >>>>>> > >>>>>> > >>>>>> On 2018年01月14日 18:32, Ilan Schwarts wrote: > >>>>>>> Thank you for clarification. > >>>>>>> Just 2 quick questions, > >>>>>>> 1. Sub volumes - 2 sub volumes cannot have 2 same inode > numbers ? > >>>>>> > >>>>>> They can. > >>>>>> > >>>>>> So to really locate an inode in btrfs, you need: > >>>>>> > >>>>>> fsid (locate the fs) -> subvolume id (locate subvolume) -> > inode number. > >>>>>> > >>>>>> fsid can be feteched from superblock as mentioned in previous > reply. > >>>>>> > >>>>>> subvolume id can be get from BTRFS_I(inode)->root. > >>>>>> And normally root is what you need. > >>>>>> > >>>>>> If you really want the number, then either > >>>>>> BTRFS_I(inode)->root->objectid or > >>>>>> BTRFS_I(inode)->root->root_key->objectid will give you the > u64 subvolume id. > >>>>>> > >>>>>>> 2. Why fsInfo fsid return u8 and the traditional file system > return > >>>>>>> dev_t, usually 32 integer ? > >>>>>> > >>>>>> As far as I found in xfs or ext4, their fsid is still u8[16] > or uuid_t, > >>>>>> same as btrfs. > >>>>>> > >>>>>> For ext4 it's ext4_super_block->s_uuid[16] > >>>>>> And for xfs, it's xfs_sb->sb_uuid. > >>>>>> > >>>>>> I don't know how you get the dev_t parameter. > >>>>>> > >>>>>> Thanks, > >>>>>> Qu > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Sun, Jan 14, 2018 at 12:22 PM, Qu Wenruo > <quwenruo.bt...@gmx.com <mailto:quwenruo.bt...@gmx.com>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2018年01月14日 18:13, Ilan Schwarts wrote: > >>>>>>>>> both btrfs filesystems will have same fsid ? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Sun, Jan 14, 2018 at 12:06 PM, Ilan Schwarts > <ila...@gmail.com <mailto:ila...@gmail.com>> wrote: > >>>>>>>>>> But both filesystems will have same fsid? > >>>>>>>>>> > >>>>>>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" > <nbori...@suse.com <mailto:nbori...@suse.com>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 14.01.2018 12:02, Ilan Schwarts wrote: > >>>>>>>>>>>> First of all, Thanks for response ! > >>>>>>>>>>>> So if i have 2 btrfs file system on the same machine > (not your > >>>>>>>>>>>> everyday scenario, i know) > >>>>>>>> > >>>>>>>> Not a problem, the 2 filesystems will have 2 different fsid. > >>>>>>>> > >>>>>>>> (And it's my everyday scenario, since fstests neeeds > TEST_DEV and > >>>>>>>> SCRATCH_DEV_POOL) > >>>>>>>> > >>>>>>>>>>>> Lets say a file is created on device A, the file gets > inode number X > >>>>>>>>>>>> is it possible on device B to have inode number X also ? > >>>>>>>>>>>> or each device has its own Inode number range ? > >>>>>>>> > >>>>>>>> Forget the mess about device. > >>>>>>>> > >>>>>>>> Inode is bounded to a filesystem, not bounded to a device. > >>>>>>>> > >>>>>>>> Just traditional filesytems are normally bounded to a > single device. > >>>>>>>> (Although even traditional filesystems can have external > journal devices) > >>>>>>>> > >>>>>>>> So there is nothing to do with device at all. > >>>>>>>> > >>>>>>>> And you can have same inode numbers in different > filesystems, but > >>>>>>>> BTRFS_I(inode)->root->fs_info will point to different > fs_infos, with > >>>>>>>> different fsid. > >>>>>>>> > >>>>>>>> So return to your initial question: > >>>>>>>>> both btrfs filesystems will have same fsid ? > >>>>>>>> > >>>>>>>> No, different filesystems will have different fsid. > >>>>>>>> > >>>>>>>> (Unless you're SUUUUUUUUUUUUUUUUUUUPER lucky to have 2 > filesystems with > >>>>>>>> same fsid) > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Qu > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Of course it is possible. Inodes are guaranteed to be > unique only across > >>>>>>>>>>> filesystem instances. In your case you are going to have > 2 fs instances. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I need to create unique identifier for a file, I need > to understand if > >>>>>>>>>>>> the identifier would be: GlobalFSID_DeviceID_Inode or > DeviceID_Inode > >>>>>>>>>>>> is enough. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Sun, Jan 14, 2018 at 11:13 AM, Qu Wenruo > <quwenruo.bt...@gmx.com <mailto:quwenruo.bt...@gmx.com>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 2018年01月14日 16:33, Ilan Schwarts wrote: > >>>>>>>>>>>>>> Hello btrfs developers/users, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I was wondering regarding to fetching the correct > fsid on btrfs from > >>>>>>>>>>>>>> the context of a kernel module. > >>>>>>>>>>>>> > >>>>>>>>>>>>> There are two IDs for btrfs. (in fact more, but you > properly won't need > >>>>>>>>>>>>> the extra ids) > >>>>>>>>>>>>> > >>>>>>>>>>>>> FSID: Global one, one fs one FSID. > >>>>>>>>>>>>> Device ID: Bonded to device, each device will have one. > >>>>>>>>>>>>> > >>>>>>>>>>>>> So in case of 2 devices btrfs, each device will has > its own device id, > >>>>>>>>>>>>> while both of the devices have the same fsid. > >>>>>>>>>>>>> > >>>>>>>>>>>>> And I think you're talking about the global fsid > instead of device id. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> if on suse11.3 kernel 3.0.101-0.47.71-default in > order to get fsid, I > >>>>>>>>>>>>>> do the following: > >>>>>>>>>>>>>> convert inode struct to btrfs_inode struct (use > btrfsInode = > >>>>>>>>>>>>>> BTRFS_I(inode)), then from btrfs_inode struct i go to > root field, and > >>>>>>>>>>>>>> from root i take anon_dev or anon_super.s_dev. > >>>>>>>>>>>>>> struct btrfs_inode *btrfsInode; > >>>>>>>>>>>>>> btrfsInode = BTRFS_I(inode); > >>>>>>>>>>>>>> btrfsInode->root->anon_super.s_dev or > >>>>>>>>>>>>>> btrfsInode->root->anon_dev - depend on kernel. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The most directly method would be: > >>>>>>>>>>>>> > >>>>>>>>>>>>> btrfs_inode->root->fs_info->fsid. > >>>>>>>>>>>>> (For newer kernel, as I'm not familiar with older kernels) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Or from superblock: > >>>>>>>>>>>>> btrfs_inode->root->fs_info->super_copy->fsid. > >>>>>>>>>>>>> (The most reliable one, no matter which kernel version > you're using, as > >>>>>>>>>>>>> long as the super block format didn't change) > >>>>>>>>>>>>> > >>>>>>>>>>>>> For device id, it's not that commonly used unless > you're dealing with > >>>>>>>>>>>>> chunk mapping, so I'm assuming you're referring to fsid. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> Qu > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In kernel 3.12.28-4-default in order to get the fsid, > i need to go > >>>>>>>>>>>>>> to the inode -> superblock -> device id > (inode->i_sb->s_dev) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Why is this ? and is there a proper/an official way > to get it ? > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> To unsubscribe from this list: send the line > "unsubscribe linux-btrfs" > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>> the body of a message to majord...@vger.kernel.org > <mailto:majord...@vger.kernel.org> > >>>>>>>>>>>>>> More majordomo info at > http://vger.kernel.org/majordomo-info.html > <http://vger.kernel.org/majordomo-info.html> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > > > > > > >
signature.asc
Description: OpenPGP digital signature
