On Thu, Apr 26, 2007 at 11:20:56PM +0530, Amit K. Arora wrote:
> Based on the discussion, this new patchset uses following as the
> interface for fallocate() system call:
> asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)
Ok, so now for the hard questions - what are the semantics of
FA_ALLOCATE and FA_DEALLOCATE?
For FA_ALLOCATE, it's supposed to change the file size if we
allocate past EOF, right? What's the return value supposed to
be? Zero for success, error otherwise? Does this update a/m/ctime
at all? How persistent is this preallocation? Should it be
there "forever" or for the lifetime of the currently open fd
that it was preallocated on?
For FA_DEALLOCATE, does it change the filesize at all? Or does
it just punch a hole in the file? If it does change file size,
what happens when you punch out preallocation beyond EOF?
What's the return value supposed to be?
> Currently we have two modes FA_ALLOCATE and FA_DEALLOCATE, for
> preallocation and deallocation of preallocated blocks respectively. More
> modes can be added, when required.
FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does
not change file size) so we can preallocate beyond EOF for apps which
use O_APPEND (i.e. changing file size would cause problems for them).
> 1> Implementation on other architectures (other than i386, x86_64,
> ppc64 and s390(x))
I'll have ia64 soon.
> 2> A generic file system operation to handle fallocate
> (generic_fallocate), for filesystems that do _not_ have the fallocate
> inode operation implemented.
> 3> Changes to glibc,
> a) to support fallocate() system call
> b) so that posix_fallocate() and posix_fallocate64() call
> fallocate() system call
> 4> Changes to XFS to implement the fallocate inode operation
And that's what I'm doing now, hence all the questions ;)
BTW, do you have a test program for this, or will I need to write
SGI Australian Software Group