Re: First impressions of reiserfs4

From: Andreas Dilger <adilger@clusterfs.com>
To: Oleg Drokin <green@namesys.com>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	Hans Reiser <reiser@namesys.com>,
	linux-kernel@vger.kernel.org, Nikita Danilov <god@namesys.com>
Subject: Re: First impressions of reiserfs4
Date: Mon, 8 Sep 2003 14:11:34 -0600	[thread overview]
Message-ID: <20030908141133.M18482@schatzie.adilger.int> (raw)
In-Reply-To: <20030908081206.GA17718@namesys.com>; from green@namesys.com on Mon, Sep 08, 2003 at 12:12:06PM +0400

On Sep 08, 2003  12:12 +0400, Oleg Drokin wrote:
> Hello!
> On Sun, Aug 31, 2003 at 07:14:19PM +0200, Rogier Wolff wrote:
> 
> > Would it be possible to do something like: "pretend that there
> > are always 100 million inodes free", and then report sensible
> > numbers to "df -i"? 
> 
> This won't work. No sensible numbers would be there.
> 
> > There  is no installation program that will fail with: "Sorry, 
> > you only have 100 million inodes free, this program will need
> > 132 million after installation", and it allows me a quick way 
> > of counting the number of actual files on the disk.... 
> 
> You cannot. statfs(2) only exports "Total number of inodes on disk" and
> "number of free inodes on disk" values for fs. df substracts one from
> another one to get "number of inodes in use".
> Actually we export necessary numbers through sysfs for now. And we have
> patch in our tree that just sets statfs(2) inode stuff to zero. You should
> see it after next snapshot is released.

In a way, it would have been nice if "sys_statfs64()" had implemented the
values as "files in use" and "files total" instead of the older (and less
useful "files free").

However, that doesn't mean you can't return something useful to statfs().
Since the linux VFS limits us to 2^32 - 1 inodes for now, you could still
return 2^32 - 1 - num_in_use for "f_ffree" and 2^32 -1 for f_files, so that
"df -i" shows a useful number for IUsed.

Sadly, the sys_statfs64() API is broken such that the filesystem can't make
a distinction between being called from sys_statfs64() and sys_statfs(),
so you have to assume the 32-bit limits even for the 64-bit API.  We should
really have a new FS method which is "statfs64()" that is optionally called
from sys_statfs64() so the FS has a chance to return something different for
64-bit callers.

For Lustre, we can't be guaranteed to fit into the 32-bit f_blocks counts
with 100TB filesystems, so we scale the f_bsize until the f_blocks fits into
32 bits.  However, we would like to be able to return the correct values to
sys_statfs64() if possible.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/