From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net ([212.227.15.19]:50729 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750837AbeANKXN (ORCPT ); Sun, 14 Jan 2018 05:23:13 -0500 Subject: Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525 To: Ilan Schwarts , Nikolay Borisov Cc: linux-btrfs References: <20170301180817.GJ4662@suse.cz> <60b03797-ff8b-0e51-f72c-66e0ada596b7@suse.com> From: Qu Wenruo Message-ID: <1431a38e-f7ec-3286-a468-50bce9a952da@gmx.com> Date: Sun, 14 Jan 2018 18:22:57 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HB56VOoDmsvweZVe7zUF5KrVMOefwf6fW" Sender: linux-btrfs-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HB56VOoDmsvweZVe7zUF5KrVMOefwf6fW Content-Type: multipart/mixed; boundary="qOQaDjhInIsmcwla5t4H8MHlIq3YieLch"; protected-headers="v1" From: Qu Wenruo To: Ilan Schwarts , Nikolay Borisov Cc: linux-btrfs Message-ID: <1431a38e-f7ec-3286-a468-50bce9a952da@gmx.com> Subject: Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525 References: <20170301180817.GJ4662@suse.cz> <60b03797-ff8b-0e51-f72c-66e0ada596b7@suse.com> In-Reply-To: --qOQaDjhInIsmcwla5t4H8MHlIq3YieLch Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018=E5=B9=B401=E6=9C=8814=E6=97=A5 18:13, Ilan Schwarts wrote: > both btrfs filesystems will have same fsid ? >=20 >=20 > On Sun, Jan 14, 2018 at 12:06 PM, Ilan Schwarts wrot= e: >> 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 acr= oss >>> filesystem instances. In your case you are going to have 2 fs instanc= es. >>> >>>> >>>> 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 Schwarts wrote: >>>>>> Hello btrfs developers/users, >>>>>> >>>>>> I was wondering regarding to fetching the correct fsid on btrfs fr= om >>>>>> 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 =3D >>>>>> 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 =3D 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 wi= th >>>>> 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-bt= rfs" >>>>>> in >>>>>> the body of a message to majordomo@vger.kernel.org >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html= >>>>>> >>>>> >>>> >>>> >>>> >=20 >=20 >=20 --qOQaDjhInIsmcwla5t4H8MHlIq3YieLch-- --HB56VOoDmsvweZVe7zUF5KrVMOefwf6fW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFLBAEBCAA1FiEELd9y5aWlW6idqkLhwj2R86El/qgFAlpbL4IXHHF1d2VucnVv LmJ0cmZzQGdteC5jb20ACgkQwj2R86El/qhm8wf/XM4h5nBF+j05NzyJ23K1HWuI Bl3kbQ84SDmsGv3QKT8So7tM6omJ+3Hg2q6r0I/DVyYBgWaV25525+6NL5iU2oXi zX6rcHgQGCvYcC4MDZGfJ/SH0MVR4Hu+h8jZ+QLSdHhAXjAgiy6UTH3sD5/ysFXx hejKhGok2zcmC70lRQTMxxbzJUATM4lLaqeDfqQynO8Tqa+7uibAgGTuGUcsrCIf n0xMxo9IHLVAKiu301eCZYOxaV3PHhGtCdbka0kcuNgwHyjLsEje94jK32s4Nx/B 4JoXBE35fbywB+MqxvH7U1PjRl9rDR4J0vuKnSHObH1qE4VVv+2qvAQZ/A7dqw== =57Hj -----END PGP SIGNATURE----- --HB56VOoDmsvweZVe7zUF5KrVMOefwf6fW--