Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

Hello btrfs developers/users,

I was wondering regarding to fetching the correct fsid on btrfs from
the context of a kernel module.
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.

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 ?

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1771 bytes --]



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.

Or from superblock:
btrfs_inode->root->fs_info->super_copy->fsid.

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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1951 bytes --]



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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

First of all, Thanks for response !
So if i have 2 btrfs file system on the same machine (not your
everyday scenario, i know)
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 ?

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.btrfs@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Nikolay Borisov]

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)
> 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 ?

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.btrfs@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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 
> 
> 

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

both btrfs filesystems will have same fsid ?


On Sun, Jan 14, 2018 at 12:06 PM, Ilan Schwarts <ilan84@gmail.com> wrote:
> But both filesystems will have same fsid?
>
> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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)
>> > 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 ?
>>
>> 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.btrfs@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 majordomo@vger.kernel.org
>> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >>>
>> >>
>> >
>> >
>> >



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 4320 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

Thank you for clarification.
Just 2 quick questions,
1. Sub volumes - 2 sub volumes cannot have 2 same inode numbers ?
2. Why fsInfo fsid return u8 and the traditional file system return
dev_t, usually 32 integer ?


On Sun, Jan 14, 2018 at 12:22 PM, Qu Wenruo <quwenruo.btrfs@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 <ilan84@gmail.com> wrote:
>>> But both filesystems will have same fsid?
>>>
>>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 5373 bytes --]

On Sun, Jan 14, 2018 at 12:32:25PM +0200, Ilan Schwarts wrote:
> Thank you for clarification.
> Just 2 quick questions,
> 1. Sub volumes - 2 sub volumes cannot have 2 same inode numbers ?

   Incorrect. You can have two subvolumes of the same filesystem, and
you can have files with the same inode number in each subvolume. Each
subvolume has its own inode number space. So an inode number on its
own is not enough to uniquely identify a file -- you also need the
subvolid to uniquely identify a specific file in the filesystem.

   Hugo.

> 2. Why fsInfo fsid return u8 and the traditional file system return
> dev_t, usually 32 integer ?
> 
> 
> On Sun, Jan 14, 2018 at 12:22 PM, Qu Wenruo <quwenruo.btrfs@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 <ilan84@gmail.com> wrote:
> >>> But both filesystems will have same fsid?
> >>>
> >>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 ?

-- 
Hugo Mills             | Gentlemen! You can't fight here! This is the War
hugo@... carfax.org.uk | Room!
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                                        Dr Strangelove

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 5688 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

Qu, Thank you very much for detailed response.

I would like to understand something, on VFS, it is guaranteed that in
a given filesystem, only 1 inode number will be used, it is unique.
In btrfs, you say the inode uniqueness is per volume, each volume has
its own inode space, How is it possible ?

Thats why when I execute "stat /somepath/file" I receive fsid that
looks like "36h/54d" but from kernel code, If I examine struct
fs_info->fsid i get 52.
I call this Physical/Virtual, physical is the real id - 52, and
virtual is 36h/54d, because this what btrfs implementation returns..
from where is that property taken ?

The inode number inode->i_ino is the same from both userspace (stat
...) and kernel code.

If on the same filesystem (52), you say, same inode number can be
used, as long as they are on different volumes - Is it possible ?
Doesn't it break the VFS inode uniqueness ?
Is there also a virtual/physical inode numbers ? and if so, is it
possible to get from kernel structure ? because inode->i_ino always
return what stat returns.. unlike fsid as i wrote above.

Thanks !!





On Sun, Jan 14, 2018 at 12:44 PM, Qu Wenruo <quwenruo.btrfs@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.btrfs@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 <ilan84@gmail.com> wrote:
>>>>> But both filesystems will have same fsid?
>>>>>
>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 9833 bytes --]



On 2018年01月15日 17:05, Ilan Schwarts wrote:
> Qu, Thank you very much for detailed response.
> 
> I would like to understand something, on VFS, it is guaranteed that in
> a given filesystem, only 1 inode number will be used, it is unique.> In btrfs, you say the inode uniqueness is per volume, each volume has
> its own inode space, How is it possible ?


Not 100% sure on how VFS should handle an inode, but since each
filesystem has its own interfaces to handle inode allocation/drop/evict
and etc, I don't believe VFS will be so stupid to just use a u64 inode
number to distinguish different inodes (if VFS really needs to).

And since each inode is allocated by implementing fs, it's completely
fine for two VFS inodes have same inode number.
But in fact such two inodes will still be different as their fs-specific
inode structures are still different.

> 
> Thats why when I execute "stat /somepath/file" I receive fsid that
> looks like "36h/54d" but from kernel code, If I examine struct
> fs_info->fsid i get 52.

That's not FSID!!

That's device!

Define what you really need first.

For FSID, that should be something in lsblk output like:
├─nvme0n1p1     vfat           5188-EF6C                    /boot
  ├─system-root xfs            07179caf-b406-4357-8cd8-3268c6238fb6   /
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                               This is FSID! ID to identify a fs.

And each fs can have their own FSID schema, just as you can see, FAT32
FSID is only 4 bytes, while XFS has 16 bytes FSID.

So there is no generic way to get a fsid.

And the "false" fsid is just device, just like stat command shows:
stat  /mnt/btrfs/
  File: /mnt/btrfs/
  Size: 6         	Blocks: 0          IO Block: 4096   directory
Device: fe00h/65024d	Inode: 75732       Links: 2
^^^^^^

And for btrfs, I'm not pretty sure if the device of an inode has any
real meaning.

> I call this Physical/Virtual, physical is the real id - 52, and
> virtual is 36h/54d, because this what btrfs implementation returns..
> from where is that property taken ?

Don't call it, check all man pages of stat first.

And I really don't understand how you get the wrong understanding of fsid.
There is even no string "fsid" in include/linux/fs.h.

> 
> The inode number inode->i_ino is the same from both userspace (stat
> ...) and kernel code.
> 
> If on the same filesystem (52)

Check the correct man pages.
That 52 is your major and minor block device number of the device for
the containing fs.

>, you say, same inode number can be
> used, as long as they are on different volumes - Is it possible ?

So in short, yet.

> Doesn't it break the VFS inode uniqueness ?

No. VFS inode is just part of fs-specific inode structure.
In btrfs' case, VFS inode is just btrfs_inode->vfs_inode.

So even vfs_inode have same inode number, they are still different inodes.

> Is there also a virtual/physical inode numbers ?

That's device. And yes it's possible to get that device number.
But almost meaningless for btrfs, since btrfs can be across several disks.

(This needs to understand btrfs chunk mapping first)

> and if so, is it
> possible to get from kernel structure ?

For what reason? It's not that useful in btrfs.

> because inode->i_ino always
> return what stat returns.. unlike fsid as i wrote above.

I think you should build a correct understanding of what an
inode/filesystem is.

And most importantly, read newer kernel source instead of some ancient
random vendor specified kernel source.

Thanks,
Qu

> 
> Thanks !!
> 
> 
> 
> 
> 
> On Sun, Jan 14, 2018 at 12:44 PM, Qu Wenruo <quwenruo.btrfs@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.btrfs@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 <ilan84@gmail.com> wrote:
>>>>>> But both filesystems will have same fsid?
>>>>>>
>>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 majordomo@vger.kernel.org
>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

Qu,
Given inode, i get the fsid via: inode->i_sb->s_dev;
this return dev_t and not u8/u16



On Sun, Jan 14, 2018 at 12:44 PM, Qu Wenruo <quwenruo.btrfs@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.btrfs@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 <ilan84@gmail.com> wrote:
>>>>> But both filesystems will have same fsid?
>>>>>
>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 6428 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

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 :(



On Mon, Jan 15, 2018 at 12:01 PM, Qu Wenruo <quwenruo.btrfs@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.btrfs@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.btrfs@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 <ilan84@gmail.com> wrote:
>>>>>>> But both filesystems will have same fsid?
>>>>>>>
>>>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 majordomo@vger.kernel.org
>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 7502 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Ilan Schwarts]

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.


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.

On Mon, Jan 15, 2018 at 2:13 PM, Qu Wenruo <quwenruo.btrfs@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.btrfs@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.btrfs@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.btrfs@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 <ilan84@gmail.com> wrote:
>>>>>>>>> But both filesystems will have same fsid?
>>>>>>>>>
>>>>>>>>> On Jan 14, 2018 12:04, "Nikolay Borisov" <nborisov@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.btrfs@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 majordomo@vger.kernel.org
>>>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 


-
Ilan Schwarts

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 11139 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: Fwd: Fwd: Question regarding to Btrfs patchwork /2831525

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 15171 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]