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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/