btrfs lacking inode or file count?
I'm just starting to do some testing with btrfs and I noticed that "df -i" doesn't give any sensible output:
backup01 ~ # df -i /mnt/backup01-p1/
Filesystem Inodes IUsed IFree IUse% Mounted on/dev/mapper/backup01p1
0 0 0 - /mnt/backup01-p1
backup01 ~ # df -h /mnt/backup01-p1/
Filesystem Size Used Avail Use% Mounted on/dev/mapper/backup01p1
20T 444G 20T 3% /mnt/backup01-p1 backup01 ~ # btrfs file show Label: 'backup01-p1' uuid: d6a87326-b28b-425a-9c80-0e4b31dfe951 Total devices 1 FS bytes used 431.13GB devid 1 size 20.00TB used 454.29GB path /dev/dm-3
Is it too difficult to provide the number of inodes in use or is this just not yet implemented?
If inodes are difficult, would the number of files (ideally per subvolume) be easier to obtain?
Quoted 2 lines · Jens Rosenboom
I'm just starting to do some testing with btrfs and I noticed that "df -i" doesn't give any sensible output:
Btrfs has dynamic inode allocation (like zfs), so it (should) never runs out of "available inodes" (only "out of space").
It's a feature, not a bug :-)
Christian.
Signature · 3 lines
BOFH excuse #110: The rolling stones concert down the road caused a brown out
Am 07.03.11 18:38, schrieb Christian Kujau:
Quoted 7 lines · Jens Rosenboom
Quoted 2 lines
I'm just starting to do some testing with btrfs and I noticed that "df -i" doesn't give any sensible output:
Btrfs has dynamic inode allocation (like zfs), so it (should) never runs out of "available inodes" (only "out of space").
It's a feature, not a bug :-)
Dynamic inode allocation surely is a nice feature, but easily being able to get the total number of files in a file system is another one and I am missing the latter.
For subvolumes it might probably be related to
https://btrfs.wiki.kernel.org/index.php/UseCases#How_I_can_know_how_much_space_is_used_by_a_volume.3F
but if there would be a way to compute the number of files in a subvolume more easily, that might be a useable first order approximation of space usage.
FWIW, it seems that ZFS can give away all these data[1] rather easily, so it doesn't look to me like the lack of these features is a direct consequence of having dynamic inode allocation. Either there is another design decision that has this effect, or it is just lack of implementation. (And in the latter case I might hope for this to change.)
[1] Number of files, total space used by a snapshot, space uniquely used by a snapshot - the latter will correspond to the space that can be freed by deleting the snapshot