Implement posix_fallocate()

[korli]

See ​http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html

[axeld]

Since we do not support sparse files yet, this one should be pretty easy to implement. To do it correctly, though, we would need to pass that function directly to the file system.

[korli]

Replying to axeld:

Since we do not support sparse files yet, this one should be pretty easy to implement. To do it correctly, though, we would need to pass that function directly to the file system.

You mean a new FS hook, right? How does this differ from ftruncate btw ?

[axeld]

1. it does not cut the file if the size given is smaller than the file size.
2. it actually allocates the storage, ie. makes sparse files no longer sparse in that region.

While a.) could be solved by the caller, b.) needs to have file system support.

[korli]

I'm in the process of adding the following call to struct fs_vnode_ops in headers/os/drivers/fs_interface.h (just after write_stat()):

status_t fallocate(fs_volume* volume, fs_vnode* vnode, off_t offset, off_t len);

Some objections?

[axeld]

Yes - the name is awful. I would just call it preallocate(). Beyond that, it might not always be simple to implement, and I am unsure if we would need to return "ok" in that case anyway.

[bonefish]

Replying to korli:

I'm in the process of adding the following call to struct fs_vnode_ops in headers/os/drivers/fs_interface.h (just after write_stat()):

status_t fallocate(fs_volume* volume, fs_vnode* vnode, off_t offset, off_t len);

Some objections?

Nope, but don't forget add the call also to the fs_shell and userlandfs.

Replying to axeld:

Yes - the name is awful. I would just call it preallocate().

+1

Beyond that, it might not always be simple to implement, and I am unsure if we would need to return "ok" in that case anyway.

Then the function wouldn't make much sense. The whole point is that after a successful call of the function, writes cannot fail due to lack of disk space. If the file system can't ensure that, it has to fail, returning a suitable error code (ENOSYS or ENOTSUP).

[axeld]

Replying to bonefish:

Then the function wouldn't make much sense. The whole point is that after a successful call of the function, writes cannot fail due to lack of disk space. If the file system can't ensure that, it has to fail, returning a suitable error code (ENOSYS or ENOTSUP).

It's filed under realtime extensions, so I guess it's purpose is not only to ensure there is enough space left (you can always at least check if there is enough space, and you could always just enlarge the file before writing it if you actually know its size beforehand), but also to make sure there is no time wasted making space for it (to be able to guarantee a certain drive throughput).

[bonefish]

Replying to axeld:

It's filed under realtime extensions, so I guess it's purpose is not only to ensure there is enough space left (you can always at least check if there is enough space, and you could always just enlarge the file before writing it if you actually know its size beforehand), but also to make sure there is no time wasted making space for it (to be able to guarantee a certain drive throughput).

I'm certain that the intended main purpose of the function is realtime use -- i.e. allocate now, don't wait later -- but still the function is supposed to do the allocation. If the underlying file system doesn't implement it, I think the function should fail, since it can neither be guaranteed that a later write will not fail due to lack of space, nor that the expected realtime behavior will ensue.

It certainly wouldn't harm to check how that works on other POSIX platforms (Linux, *BSD). It might not be easy to find a file system implementation that cannot implement this feature -- maybe some network file system.

[korli]

I added a call in hrev39006.

[luroh]

Move POSIX compatibility related tickets out of R1 milestone (FutureHaiku/Features).

[korli]

Proposed change ​https://review.haiku-os.org/c/haiku/+/3382

[cocobean]

NOTE: Patches merged in Nov 2020. Verified on Dec 3, 2020 - hrev54754.

[pulkomandy]

Right, ​https://review.haiku-os.org/c/haiku/+/3382 has been merged.