[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45EC3415.6000307@redhat.com>
Date: Mon, 05 Mar 2007 07:15:33 -0800
From: Ulrich Drepper <drepper@...hat.com>
To: Theodore Tso <tytso@....edu>, Arnd Bergmann <arnd@...db.de>,
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
Subject: Re: [RFC] Heads up on sys_fallocate()
Theodore Tso wrote:
> Given that glibc already has to support this for older kernels, I
> would argue that there's no point putting in generic support for
> filesystem that can't support a more advanced way of doing things.
Well, I'm sure the kernel can do better than the code we have in libc
now. The kernel has access to the bitmasks which say which blocks have
already been allocated. The libc code does not and we have to be very
simple-minded and simply touch every block. And this means reading it
and then writing it back. The kernel would know when the reading part
is not necessary. Add to then the block granularity (we use f_bsize as
returned from fstatfs but that's not the best value in some cases) and
you have compelling data to have generic code in the kernel. Then libc
implementation can then go away completely which is a good thing.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)
Powered by blists - more mailing lists