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