> >On Fri, 02 Mar 2007 09:40:54 +1100 > >Nathan Scott <nscott@xxxxxxxxxx> wrote: > > > > > >>On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote: > >> > >>>On Fri, 2 Mar 2007 00:04:45 +0530 > >>>"Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> > >>>>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 <jack@xxxxxxx> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
