All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Rosenboom <j.rosenboom@syseleven.de>
To: Christian Kujau <lists@nerdbynature.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs lacking inode or file count?
Date: Tue, 08 Mar 2011 10:45:07 +0100	[thread overview]
Message-ID: <4D75FAA3.7090309@syseleven.de> (raw)
In-Reply-To: <alpine.DEB.2.01.1103070935550.23816@trent.utfs.org>

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


      reply	other threads:[~2011-03-08  9:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-07 16:17 btrfs lacking inode or file count? Jens Rosenboom
2011-03-07 17:38 ` Christian Kujau
2011-03-08  9:45   ` Jens Rosenboom [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D75FAA3.7090309@syseleven.de \
    --to=j.rosenboom@syseleven.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@nerdbynature.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.