>It's cut down by a factor of thousand on a 4k filesystem.
>
>AND on top of that the lookup is faster anyway, because there are much
>fewer buffers on the hashes.
I think the major issue with fsync is having to read from disk in order to
complete the operation. The fact that we don't have to lookup the buffer
cache anymore to check if there's a dirty buffer in memory will sure cut
down the complexity of the operation, but according to me the real issue
is to avoid read-I/O from disk (think if you have only one block dirty in
the metadata (after an append of data to an inode), in such case you don't
want to generate lots of read-I/O just to write 1k to disk).
fdatasync instead is just _fine_ in this regard.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/