This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Extended file stat: Splitting file- and fs-specific info?
- From: David Howells <dhowells at redhat dot com>
- To: Dave Chinner <david at fromorbit dot com>
- Cc: dhowells at redhat dot com, adilger at dilger dot ca, bfields at fieldses dot org, smfrench at gmail dot com, ben at decadent dot org dot uk, Trond dot Myklebust at netapp dot com, roland at hack dot frob dot com, 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, linux-api at vger dot kernel dot org, libc-alpha at sourceware dot org
- Date: Thu, 10 May 2012 10:14:11 +0100
- Subject: Re: Extended file stat: Splitting file- and fs-specific info?
- References: <20120509002420.GL5091@dastard> <20120419140558.17272.74360.stgit@warthog.procyon.org.uk> <16281.1336508382@redhat.com>
Dave Chinner <david@fromorbit.com> wrote:
> > Also, do Dave Chinner's ideas for indicating five I/O parameters want to be
> > 32-bit numbers? Larger? Smaller? Can they be log2?
>
> Definitely 32 bit, IMO, as it's not uncommon to see optimal IO sizes
> in the tens of megabytes on large, high bandwidth storage systems.
> As for being log2 - that's just making it more complex to use and
> making code ugly - we'd have to convert to log2 in kernel, then
> convert back in every single application....
ilog2() in the kernel uses the CPU's bit-scan instruction if it has one and
converting back is just a bitshift operator.
But let's go with 32-bit fields for the moment. I presume we aren't worried
about a driver that wants to do a 4GB transfer...
David