lkml.org 
[lkml]   [2007]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Heads up on sys_fallocate()
    Andrew Morton wrote:

    > On Fri, 02 Mar 2007 09:40:54 +1100
    > Nathan Scott <nscott@aconex.com> 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@linux.vnet.ibm.com> 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.

    Right now neither ext4 preallocation implementation or reservation are
    guranteed to allocate/reserve contigugous extents. If the application
    told it so, it could do more searching to satisfy the requirement.

    Or fadvise is the right interface?

    Mingming
    > I'm inclined to merge this patch nice and early, so the syscall number is
    > stabilised. Otherwise the people who are working on out-of-tree code (ie:
    > ext4) will have to keep playing catchup.
    >


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-02 19:31    [W:4.106 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site