Jamie Lokier wrote:
> 3rd choice: preallocate space with room for interleaved indirection
> blocks.
Sorry I take that thinko back. Too little sleep last night :-)
-- Jamie
Stephen C. Tweedie wrote:
> No. If we do posix_fallocate(), then there are only two choices:
> we either pre-zero the file contents (in which case we are as well
> doing it from user space), or we record in the inode that the file
> isn't pre-zeroed and so optimise things.
3rd choice: preallocat
Hi,
On Fri, Jun 09, 2000 at 02:51:18PM -0700, Ulrich Drepper wrote:
>
> Have you thought about O_RSYNC and whether it is possible/useful to
> support it separately?
It would be possible and useful, but it's entirely separate from the
write path and probably doesn't make sense until we've got O_
Sorry for the separate mail:
"Stephen C. Tweedie" <[EMAIL PROTECTED]> writes:
> If I don't preallocate the file, then even fdatasync is slow, [...]
This might be a good argument to implement posix_fallocate() in the
kernel.
--
---. drepper at gnu.org ,-. 1325 Chesapeake Te
Hi,
On Fri, Jun 09, 2000 at 02:53:19PM -0700, Ulrich Drepper wrote:
>
> > If I don't preallocate the file, then even fdatasync is slow, [...]
>
> This might be a good argument to implement posix_fallocate() in the
> kernel.
No. If we do posix_fallocate(), then there are only two choices:
we e
"Stephen C. Tweedie" <[EMAIL PROTECTED]> writes:
> * Old applications which specified O_SYNC will continue
> to get their expected (O_DSYNC) behaviour
>
> * New applications can specify O_SYNC or O_DSYNC and get
> the selected behaviour on new kernels
>
> * New
