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 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 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 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 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 wrote: >>>>>>>>>> But both filesystems will have same fsid? >>>>>>>>>> >>>>>>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" 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 >>>>>>>>>>>> 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 majordomo@vger.kernel.org >>>>>>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > >