Re: Why does stat() return invalid st_dev field for btrfs ??

Re: Why does stat() return invalid st_dev field for btrfs ??

[Mark Lord]

Mark Lord wrote:
>
> stat(2) seems to return invalid major/minor device info
> for btrfs filesystems.
> 
> Why?  Is this a bug?
> 
> Eg.
> 
>     [~] uname -r
>     2.6.31-rc6
>     [~] mkfs.btrfs /dev/sdb
>     
>     WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
>     WARNING! - see http://btrfs.wiki.kernel.org before using
>     
>     fs created label (null) on /dev/sdb
>             nodesize 4096 leafsize 4096 sectorsize 4096 size 30.06GB
>     Btrfs Btrfs v0.19
>     [~] mount /dev/sdb /x -t btrfs
>     [~] stat --format="%04D" /x
>     0017
>     [~] touch /x/junk
>     [~] stat --format="%04D" /x/junk
>     0017
> 
> This gives major=0x00, minor=0x17 for /dev/sdb,
> which should have major=8, minor=0x10.
> 
> ???

> Chris Ball wrote:
>> Hi,
>>
>>    > Mmm.. btrfs appears to configure itself as a "pseudo" filesystem,
>>    > which is why it returns fake device numbers via stat(), similar
>>    > to procfs or sysfs.
>>
>> Probably because a single btrfs filesystem can be composed of multiple
>> devices; one major/minor would not be sufficient.
> ..
> 
> So I'm seeing in the code.
> 
> But for the 99% common case (personal computers, one drive), it would be
> rather useful it it would comply with filesystem standards there.
> 
> In the unlikely event that a btrfs actually is composed of multiple 
> devices,
> then in that case perhaps return something nonsensical.
> 
> Mmm.. don't we already *have* an LVM layer in Linux?
> 
> Seems like a rather bad idea to have a new Linux-specific
> filesystem re-implement it's own private LVM, and thus
> confuse various disk management tools and the like.
..

[added linux-kernel to CC: list]

Along those lines -- since btrfs reports invalid device information to stat(2),
then I would suggest that it should also return -ENOTSUP for the FIBMAP and FIEMAP
ioctl() calls.  Otherwise, somebody's filesystem is going to get corrupted.

Cheers

Re: Why does stat() return invalid st_dev field for btrfs ??

[Mark Lord]

Kay Sievers wrote:
> On Mon, Aug 17, 2009 at 22:47, Mark Lord<lkml@rtr.ca> wrote:
>> Chris / list,
>>
>> stat(2) seems to return invalid major/minor device info
>> for btrfs filesystems.
>>
>> Why?  Is this a bug?
> 
> This is not invalid and not a bug. It's a superblock without a device,
> and expected behavior.
> 
> There is no one-to-one relation from a btrfs mountpoint to a device,
> it's a tree, and therefore therefore there can not be a single
> major/minor.
..

Sure there is for the most common case.
When there is only a single device, stat() should return that device.
When there are several, it should do something different.

But really, it should be using DM/LVM when there are multiple devices.

Re: Why does stat() return invalid st_dev field for btrfs ??

[Jens Axboe]

On Mon, Aug 17 2009, Mark Lord wrote:
> Kay Sievers wrote:
>> On Mon, Aug 17, 2009 at 22:47, Mark Lord<lkml@rtr.ca> wrote:
>>> Chris / list,
>>>
>>> stat(2) seems to return invalid major/minor device info
>>> for btrfs filesystems.
>>>
>>> Why?  Is this a bug?
>>
>> This is not invalid and not a bug. It's a superblock without a device,
>> and expected behavior.
>>
>> There is no one-to-one relation from a btrfs mountpoint to a device,
>> it's a tree, and therefore therefore there can not be a single
>> major/minor.
> ..
>
> Sure there is for the most common case.
> When there is only a single device, stat() should return that device.
> When there are several, it should do something different.

I actually think it's quite sane, since then you get the same behaviour
on multi vs single disk file systems. The last thing you want is to have
different behaviour when you later add a disk, for instance.

-- 
Jens Axboe