Opened 9 years ago

Last modified 5 years ago

#6285 new enhancement

Implement posix_fallocate()

Reported by: korli Owned by: nobody
Priority: low Milestone: Unscheduled
Component: System/POSIX Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Change History (10)

comment:1 by axeld, 9 years ago

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.

in reply to:  1 comment:2 by korli, 9 years ago

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 ?

comment:3 by axeld, 9 years ago

  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.

comment:4 by korli, 9 years ago

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?

comment:5 by axeld, 9 years ago

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.

in reply to:  5 ; comment:6 by bonefish, 9 years ago

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

in reply to:  6 ; comment:7 by axeld, 9 years ago

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

in reply to:  7 comment:8 by bonefish, 9 years ago

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.

comment:9 by korli, 9 years ago

I added a call in hrev39006.

comment:10 by luroh, 5 years ago

Milestone: R1Unscheduled

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

Note: See TracTickets for help on using tickets.