This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/6] xstat: Add a pair of system calls to make extendedfile stats available
- From: Dave Chinner <david at fromorbit dot com>
- To: David Howells <dhowells at redhat dot com>
- Cc: Andreas Dilger <adilger at dilger dot ca>, linux-fsdevel at vger dot kernel dot org,linux-nfs at vger dot kernel dot org, linux-cifs at vger dot kernel dot org,samba-technical at lists dot samba dot org, linux-ext4 at vger dot kernel dot org,wine-devel at winehq dot org, kfm-devel at kde dot org, nautilus-list at gnome dot org,linux-api at vger dot kernel dot org, libc-alpha at sourceware dot org
- Date: Fri, 27 Apr 2012 10:51:21 +1000
- Subject: Re: [PATCH 1/6] xstat: Add a pair of system calls to make extendedfile stats available
- References: <5D4BF4AB-47E9-4E25-B2A3-F895C98BDAA3@dilger.ca><20120419140558.17272.74360.stgit@warthog.procyon.org.uk><20120419140612.17272.57774.stgit@warthog.procyon.org.uk><18195.1335447156@redhat.com>
On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
> Andreas Dilger <adilger@dilger.ca> wrote:
> > st_blksize may be variable for a distributed filesystem,
It can be variable for local filesystems, too. XFS will vary the
block size based on the configuration of the inode. e.g. if there is
an extent allocation size hint on the inode, or it's on the realtime
device, and so on. There is no guarantee that from file to file that
it is constant.
> I wonder if there's a way to make this explicit - or is it something that if
> the bit isn't set, you can't use the value in st_blksize.
> I wonder if this
> value always has to be non-zero to make sure existing stat() doesn't explode.
More likely it probably needs to be non-zero to prevent applications
doing division by block size from exploding... ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com