lkml.org 
[lkml]   [2009]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Why does stat() return invalid st_dev field for btrfs ??
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


\
 
 \ /
  Last update: 2009-08-18 00:07    [W:0.153 / U:25.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site