posix_fallocate question again

posix_fallocate question again

[Chen, Kenneth W]

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?

Re: posix_fallocate question again

[Andrew Morton]

"Chen, Kenneth W" <kenneth.w.chen@intel.com> 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.

Re: posix_fallocate question again

[Christoph Hellwig]

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, ..)

Re: posix_fallocate question again

[Ulrich Drepper]

-----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-----

Re: posix_fallocate question again

[Nikita Danilov]

Andrew Morton writes:
 > "Chen, Kenneth W" <kenneth.w.chen@intel.com> 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.

Re: posix_fallocate question again

[Jamie Lokier]

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

Re: posix_fallocate question again

[Nikita Danilov]

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.