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?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 7 Mar 2011 at 17:17, Jens Rosenboom wrote:> 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. -- BOFH excuse #110: The rolling stones concert down the road caused a brown out -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 07.03.11 18:38, schrieb Christian Kujau:> On Mon, 7 Mar 2011 at 17:17, Jens Rosenboom wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html