Re: O_SYNC patches for 2.4.0-test1-ac11
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
Re: O_SYNC patches for 2.4.0-test1-ac11
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: preallocate space with room for interleaved indirection blocks. You don't need to record anything in the inode: it's the indirection blocks that get changed as you fill up the file. And they're in exactly the right place. -- Jamie
Re: O_SYNC patches for 2.4.0-test1-ac11
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_DIRECT working (O_RSYNC is closely related to that). Cheers, Stephen
Re: O_SYNC patches for 2.4.0-test1-ac11
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 Terrace Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `
Re: O_SYNC patches for 2.4.0-test1-ac11
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 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. If we do that optimisation, then doing an O_DSYNC write to the already-allocated file will have to record in the inode that we are pushing forward the non-prezeroed fencepost in the file, so we end up having to seek back to the inode for each write anyway, so we lose any possible benefit during the writes. Once you have a database file written and preallocated, this is all academic since all further writes will be in place and so will be fast the th O_DSYNC/fdatasync support. Cheers, Stephen
Re: O_SYNC patches for 2.4.0-test1-ac11
"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 applications calling either O_SYNC or O_DSYNC will > still get O_SYNC on old kernels. Have you thought about O_RSYNC and whether it is possible/useful to support it separately? -- ---. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `
