This has been brought up by Ulrich more than 3 years ago:
http://marc.theaimsgroup.com/?l=linux-kernel&m=95569775802945&w=2
Is there anytime soon that kernel 2.6 will have such functionality?
"Chen, Kenneth W" <[email protected]> wrote:
>
> This has been brought up by Ulrich more than 3 years ago:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=95569775802945&w=2
A decent fallocate() implementation requires that the underlying fs has a
permanent representation of blocks which are in an "allocated,
uninitialised" state. afaik XFS is the only such filesystem.
It's a fair bit of work for what doesn't really sound a very useful
feature. Doing it in libc is reasonable. Probably the libc implementation
could be improved by using ioctl(FIBMAP) and O_DIRECT to mimimise IO and
CPU utilisation.
> Is there anytime soon that kernel 2.6 will have such functionality?
Nope.
On Wed, Aug 20, 2003 at 12:07:10PM -0700, Chen, Kenneth W wrote:
> This has been brought up by Ulrich more than 3 years ago:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=95569775802945&w=2
Note that the design for posix_fallocate is stupid. We really want
a 64bit len argument even on 32bit machines.
> Is there anytime soon that kernel 2.6 will have such functionality?
On XFS you can use ioctl(.., XFS_IOC_RESVSP64, ..)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph Hellwig wrote:
> Note that the design for posix_fallocate is stupid. We really want
> a 64bit len argument even on 32bit machines.
I've submitted already a bug report for that. *Iff* somebody implements
posix_fallocate in the kernel, use
int posix_fallocate (int, off64_t, off64_t)
as the interface (or whatever the kernel equivalent is).
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/RDBI2ijCOnn/RHQRAkmmAKCeiC4KYsvBDV65wj/GNmPMIw9t6gCgxFSC
EkqBO4PyRhTxqhvz9dlHU08=
=BASe
-----END PGP SIGNATURE-----
Andrew Morton writes:
> "Chen, Kenneth W" <[email protected]> wrote:
> >
> > This has been brought up by Ulrich more than 3 years ago:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=95569775802945&w=2
>
> A decent fallocate() implementation requires that the underlying fs has a
> permanent representation of blocks which are in an "allocated,
> uninitialised" state. afaik XFS is the only such filesystem.
>
> It's a fair bit of work for what doesn't really sound a very useful
> feature. Doing it in libc is reasonable. Probably the libc implementation
> could be improved by using ioctl(FIBMAP) and O_DIRECT to mimimise IO and
> CPU utilisation.
fallocate() will be useful when writing into file through
mmap(). Currently kernel can just drop dirtied page at any moment (if
->writepage() fails with -ENOSPC), so the only safe way to modify file
through mmap() is by using mlock().
>
> > Is there anytime soon that kernel 2.6 will have such functionality?
>
> Nope.
>
Nikita.
Nikita Danilov wrote:
> fallocate() will be useful when writing into file through
> mmap(). Currently kernel can just drop dirtied page at any moment (if
> ->writepage() fails with -ENOSPC), so the only safe way to modify file
> through mmap() is by using mlock().
Isn't msync() reliable? I.e. will it at least report the error?
-- Jamie
Jamie Lokier writes:
> Nikita Danilov wrote:
> > fallocate() will be useful when writing into file through
> > mmap(). Currently kernel can just drop dirtied page at any moment (if
> > ->writepage() fails with -ENOSPC), so the only safe way to modify file
> > through mmap() is by using mlock().
>
> Isn't msync() reliable? I.e. will it at least report the error?
Seems latest 2.6 (19 Aug change sets by Andrew Morton) got support for
this: shrink_list() set AS_ENOSPC on mapping and error will later be
returned.
>
> -- Jamie
Nikita.