[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070418130600.GW5967@schatzie.adilger.int>
Date: Wed, 18 Apr 2007 07:06:00 -0600
From: Andreas Dilger <adilger@...sterfs.com>
To: "Amit K. Arora" <aarora@...ux.vnet.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Jakub Jelinek <jakub@...hat.com>,
torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org,
xfs@....sgi.com, cmm@...ibm.com, suparna@...ibm.com
Subject: Re: Interface for the new fallocate() system call
On Apr 17, 2007 18:25 +0530, Amit K. Arora wrote:
> On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote:
> > 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.
>
> I think more people are comfirtable with this approach.
Really? I thought from the last postings that "fd first, wrap on s390"
was better.
> Since glibc
> will wrap the system call and export the "conventional" interface
> (with fd first) to applications, we may not worry about keeping fd first
> in kernel code. I am personally fine with this approach.
It would seem to make more sense to wrap the syscall on those architectures
that can't handle the "conventional" interface (fd first).
> Still, if people have major concerns, we can think of getting rid of the
> "mode" argument itself. Anyhow we may, in future, need to have a policy
> based system call (say, for providing the goal block by applications for
> performance reasons). "mode" can then be made part of it.
We need at least mode="unallocate" or a separate funallocate() call to
allow allocated-but-unwritten blocks to be unallocated without actually
punching out written data.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists