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-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
