linux-kernel - Re: Why does stat() return invalid st

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 17 Aug 2009 18:03:33 -0400
From:	Mark Lord <lkml@....ca>
To:	Chris Ball <cjb@...top.org>
Cc:	linux-btrfs@...r.kernel.org, Chris Mason <chris.mason@...cle.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/