quoted

On Fri, 02 Mar 2007 09:40:54 +1100
Nathan Scott [off-list ref] wrote:

quoted

On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:

quoted

On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" [off-list ref] wrote:

quoted

This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:

asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len);

...

I'd agree with Eric on the "command" flag extension.

Seems like a separate syscall would be better, "command" sounds
a bit ioctl like, especially if that command is passed into the
filesystems..

madvise, fadvise, lseek, etc seem to work OK.

I get repeatedly traumatised by patch rejects whenever a new syscall gets
added, so I'm biased.

The advantage of a command flag is that we can add new modes in the future
without causing lots of churn, waiting for arch maintainers to catch up,
potentially adding new compat code, etc.

Rename it to "mode"? ;)

I am wondering if it is useful to add another mode to advise block 
allocation policy? Something like indicating which physical block/block 
group to allocate from (goal), and whether ask for strict contigous 
blocks. This will help preallocation or reservation to choose the right 
blocks for the file.

  Yes, I also think this would be useful so you can "guide"
preallocation for things like defragmentation (e.g. preallocate space
for the file being defragmented and move the file to it).

									Honza
-- 
Jan Kara [off-list ref]
SuSE CR Labs