[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200703042153.35425.arnd@arndb.de>
Date: Sun, 4 Mar 2007 21:53:32 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Anton Altaparmakov <aia21@....ac.uk>
Cc: Christoph Hellwig <hch@...radead.org>,
Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Amit K. Arora" <aarora@...ux.vnet.ibm.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-ext4@...r.kernel.org, suparna@...ibm.com, cmm@...ibm.com,
alex@...sterfs.com, suzuki@...ibm.com,
Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC] Heads up on sys_fallocate()
On Sunday 04 March 2007, Anton Altaparmakov wrote:
> > A generic_fallocate makes sense to me iff we can do it in the kernel
> > more significantly more efficiently than in glibc, e.g. by using only
> > a single page in page cache instead of one for each page to be
> > preallocated.
> >
> > If glibc is smart enough to do an optimal implementation, I fully
> > agree
> > with you.
>
> glibc cannot ever be smart enough because a file system driver will
> always know better and be able to do things in a much more optimized
> way.
Ok, that's not what I meant. It's obvious that the file system itself
can do better than both VFS and glibc. The question is whether VFS can
be better than glibc on file systems that don't offer their own
implementation of the fallocate operation.
Arnd <><
-
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