btrfs lacking inode or file count?

btrfs lacking inode or file count?

[Jens Rosenboom]

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?

Re: btrfs lacking inode or file count?

[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 :-)

Christian.
-- 
BOFH excuse #110:

The rolling stones concert down the road caused a brown out

Re: btrfs lacking inode or file count?

[Jens Rosenboom]

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