From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net ([212.227.15.15]:58706 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753433AbeARFuD (ORCPT ); Thu, 18 Jan 2018 00:50:03 -0500 Subject: Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525 To: Ilan Schwarts Cc: Nikolay Borisov , linux-btrfs References: <60b03797-ff8b-0e51-f72c-66e0ada596b7@suse.com> <1431a38e-f7ec-3286-a468-50bce9a952da@gmx.com> <4897b464-7212-f92c-c6cf-6fbfd04ec30c@gmx.com> <7bb8f56a-75d6-8235-5a46-d1dfe1dbf8f5@gmx.com> <09582fcd-e445-00b8-c56c-ceb845150526@gmx.com> From: Qu Wenruo Message-ID: Date: Thu, 18 Jan 2018 13:49:49 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0nrNhW8TPkDpBv58GYR6HVh42e2mrbQfF" Sender: linux-btrfs-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0nrNhW8TPkDpBv58GYR6HVh42e2mrbQfF Content-Type: multipart/mixed; boundary="m673TsqD7H9ltlRcVONDuQAv6xOrgW45P"; protected-headers="v1" From: Qu Wenruo To: Ilan Schwarts Cc: Nikolay Borisov , linux-btrfs Message-ID: Subject: Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525 References: <60b03797-ff8b-0e51-f72c-66e0ada596b7@suse.com> <1431a38e-f7ec-3286-a468-50bce9a952da@gmx.com> <4897b464-7212-f92c-c6cf-6fbfd04ec30c@gmx.com> <7bb8f56a-75d6-8235-5a46-d1dfe1dbf8f5@gmx.com> <09582fcd-e445-00b8-c56c-ceb845150526@gmx.com> In-Reply-To: --m673TsqD7H9ltlRcVONDuQAv6xOrgW45P Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018=E5=B9=B401=E6=9C=8818=E6=97=A5 13:27, Ilan Schwarts wrote: > Is there a way to retrieve this anonymous device number =C2=A0? 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 ar= e > on different filesystem, this is since they are managed by the btrfs mo= dule. 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 >=20 > On Jan 18, 2018 07:12, "Qu Wenruo" > wrote: >=20 >=20 >=20 > On 2018=E5=B9=B401=E6=9C=8817=E6=97=A5 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 > >=C2=A0 =C2=A0File: =E2=80=98/home/builder/myfile1=E2=80=99 > >=C2=A0 =C2=A0Size: 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Blocks: 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IO Block: 4096=C2=A0 > =C2=A0regular empty file > > Device: 31h/49d Inode: 549453=C2=A0 =C2=A0 =C2=A0 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 > >=C2=A0 =C2=A0File: =E2=80=98/opt=E2=80=99 > >=C2=A0 =C2=A0Size: 120=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Blocks: 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IO Block: 4096=C2=A0 =C2=A0= directory > > Device: 30h/48d Inode: 256=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Links= : 1 > > Access: (0755/drwxr-xr-x)=C2=A0 Uid: (=C2=A0 =C2=A0 0/=C2=A0 =C2=A0= root)=C2=A0 =C2=A0Gid: (=C2=A0 =C2=A0 0/=C2=A0 =C2=A0 > 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 > >=C2=A0 Birth: - > > builder@SLES12X86-64:~> stat /home > >=C2=A0 =C2=A0File: =E2=80=98/home=E2=80=99 > >=C2=A0 =C2=A0Size: 48=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Blocks: 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IO Block: 4096=C2=A0 =C2=A0= directory > > Device: 31h/49d Inode: 256=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Links= : 1 > > > > > > There are different devices (31h/49d, 30h/48d ), but it is still > /dev/sda2. >=20 > As I already said (more than once), btrfs is a multi-device filesys= tem, > so its device number is mostly meaningless. >=20 > The device number is just a meaningless (anonymous) one. >=20 > Check btrfs_set_super() to see how it set its super_block->s_dev. >=20 > > > > > > 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 =3D BTRFS_I(inode)->root->anon_dev; > > .. > > > > When printing from kernel=C2=A0 BTRFS_I(inode)->root->anon_dev - = I receive > > the number 2. and not 31h/49d. >=20 > Just as its name, it's *anonymous* device, where no device should h= ave > such device number. >=20 > And as you already checked btrfs_getattr(), why not check a step fu= ther > about generic_fillattr()? >=20 > ------ > /** > =C2=A0* generic_fillattr - Fill in the basic attributes from the in= ode struct > =C2=A0* @inode: Inode to use as the source > =C2=A0* @stat: Where to fill in the attributes > =C2=A0* > =C2=A0* Fill in the basic attributes in the kstat structure from da= ta that's > to be > =C2=A0* found on the VFS inode structure.=C2=A0 This is the default= if no getattr > inode > =C2=A0* operation is supplied. > =C2=A0*/ > void generic_fillattr(struct inode *inode, struct kstat *stat) > { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 stat->dev =3D inode->i_sb->s_dev; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 stat->ino =3D inode->i_ino; > ------ >=20 > device number is just get from superblock, and any device number > returned by fs-specific getattr function is overwritten. >=20 > And BTW, root->anon_dev is also just another anonymous device numbe= r, > set by btrfs_init_fs_root() in fs/btrfs/disk-io.c: > ------ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D get_anon_bdev(&root->anon_dev);= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ret) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto fail; > ------ >=20 > Thanks, > Qu >=20 > > > > On Mon, Jan 15, 2018 at 2:13 PM, Qu Wenruo > wrote: > >> > >> > >> On 2018=E5=B9=B401=E6=9C=8815=E6=97=A5 20:08, Ilan Schwarts wrot= e: > >>> Thanks for detailed information ! > >>> Its a legacy code for kernel module i maintain.. dont talk to m= e > 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 fo= r > btrfs. > >> > >> Thanks, > >> Qu > >> > >>> > >>> > >>> > >>> On Mon, Jan 15, 2018 at 12:01 PM, Qu Wenruo > > wrote: > >>>> > >>>> > >>>> On 2018=E5=B9=B401=E6=9C=8815=E6=97=A5 17:24, Ilan Schwarts wr= ote: > >>>>> 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=E5=B9=B401=E6=9C=8814=E6=97=A5 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 previou= s > 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 syste= m > 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=E5=B9=B401=E6=9C=8814=E6=97=A5 18:13, Ilan Schwart= s 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 fsi= d. > >>>>>>>> > >>>>>>>> (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 hav= e > 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=E5=B9=B401=E6=9C=8814=E6=97=A5 16:33, Ilan Sc= hwarts 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 on= e. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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 =3D > >>>>>>>>>>>>>> BTRFS_I(inode)), then from btrfs_inode struct i go t= o > root field, and > >>>>>>>>>>>>>> from root i take anon_dev or anon_super.s_dev. > >>>>>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct btrfs_inode = *btrfsInode; > >>>>>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0btrfsInode =3D BTRF= S_I(inode); > >>>>>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 btrfsInode->root->anon_su= per.s_dev=C2=A0 =C2=A0 or > >>>>>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 btrfsInode->root->anon_de= v=C2=A0 =C2=A0 - 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 ker= nels) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Or from superblock: > >>>>>>>>>>>>> btrfs_inode->root->fs_info->super_copy->fsid. > >>>>>>>>>>>>> (The most reliable one, no matter which kernel versio= n > 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 fs= id. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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=C2=A0 > http://vger.kernel.org/majordomo-info.html > > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > > > > > > >=20 --m673TsqD7H9ltlRcVONDuQAv6xOrgW45P-- --0nrNhW8TPkDpBv58GYR6HVh42e2mrbQfF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFLBAEBCAA1FiEELd9y5aWlW6idqkLhwj2R86El/qgFAlpgNX0XHHF1d2VucnVv LmJ0cmZzQGdteC5jb20ACgkQwj2R86El/qh2fQf8DzcyncVTrCqNz8adtbbZITp2 9yxIKV14kHqIK3ctGM550DTHKoS0CgP38LCAgM+L4+k+6QDF0LTQyUuIGvmGCwgN mYA2axBZ0jq1ueKheIS2Yv4r4RpCNMgqbz7z7bsw/Irr3791v7vQUU57EGXpw3Kg XUmYx1WOGQCssvMLX2SKGVFaeVjcTY6CfrI4NBHPGbR2XcV8vjEqoeYDwQ5RwNp7 8jormQtWR9Np6MzZmSVPaVTvQDq63hdcw03s5uF7BQd9qrFO6kK+KJf3ezSPoCGl U858kuIMwcH0dvTLpBrbE7kz1IITwLXopAhpPwVP4EZm94LKC0VOg5SMfOJg/Q== =q4F6 -----END PGP SIGNATURE----- --0nrNhW8TPkDpBv58GYR6HVh42e2mrbQfF--