Re: Interface for the new fallocate() system call

2007-03-30 Thread Heiko Carstens
On Thu, Mar 29, 2007 at 07:01:54PM +0200, Jan Engelhardt wrote: Hi, On Mar 29 2007 17:21, Amit K. Arora wrote: We need to come up with the best possible layout of arguments for the fallocate() system call. Various architectures have different requirements for how the arguments should look

Re: Interface for the new fallocate() system call

2007-03-30 Thread Jakub Jelinek
On Thu, Mar 29, 2007 at 10:10:10AM -0700, Andrew Morton wrote: Platform: s390 -- s390 prefers following layout: int fallocate(int fd, loff_t offset, loff_t len, int mode) For details on why and how int, int, loff_t, loff_t is a problem on s390, please see Heiko's

Re: Interface for the new fallocate() system call

2007-03-30 Thread Heiko Carstens
Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). This is a clean-looking option. Can s390 be changed to support seven-arg syscalls? Option of loff_t = high u32 + low u32 -- Matthew and

Re: Ext4 benchmarks

2007-03-30 Thread Johann Lombardi
On Wed, Mar 28, 2007 at 09:20:50AM -0500, Jose R. Santos wrote: While it may be to late for the purposes of your OLS paper, one thing that doesn't seem to be getting much attention is the performance of a file system while doing many meta-data operations or throughput testing during heavy

Re: Interface for the new fallocate() system call

2007-03-30 Thread Paul Mackerras
Jakub Jelinek writes: Wouldn't int fallocate(loff_t offset, loff_t len, int fd, int mode) work on both s390 and ppc/arm? glibc will certainly wrap it and reorder the arguments as needed, so there is no need to keep fd first. That looks fine to me. Paul. - To unsubscribe from this list:

Re: Interface for the new fallocate() system call

2007-03-30 Thread Jörn Engel
On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote: Heiko Carstens writes: If possible I'd prefer the six-32-bit-args approach. It does mean extra unnecessary work for 64-bit platforms, though... Wouldn't that work be confined to fallocate()? If I understand Heiko correctly, the

Re: Interface for the new fallocate() system call

2007-03-30 Thread Heiko Carstens
On Fri, Mar 30, 2007 at 12:44:49PM +0200, Jörn Engel wrote: On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote: It does mean extra unnecessary work for 64-bit platforms, though... Wouldn't that work be confined to fallocate()? If I understand Heiko correctly, the alternative would

Re: Ext4 benchmarks

2007-03-30 Thread Andreas Dilger
On Mar 30, 2007 10:43 +0200, Johann Lombardi wrote: On Wed, Mar 28, 2007 at 09:20:50AM -0500, Jose R. Santos wrote: While it may be to late for the purposes of your OLS paper, one thing that doesn't seem to be getting much attention is the performance of a file system while doing many