JLS2009: A Btrfs update
Posted Nov 5, 2009 13:49 UTC (Thu) by anton
In reply to: JLS2009: A Btrfs update
Parent article: JLS2009: A Btrfs update
I understood Ted T'so's apology as follows: He thinks that application
should use fsync() in lots of places, and by contributing to a better
file system where that is not necessary as much, application
developers were not punished by the file system as they should be in
his opinion, and he apologized for spoiling them in this way.
I find it odd that one minute you're complaining that filesystems are
useless because problems occur if you don't fsync(), then the next moment
you're complaining that it's too slow, then the next moment you're
complaining about the precise opposite.
Are you confusing me with someone else, are you trying to put up a
straw man, or was my position so hard to understand? Anyway, here it
- On data consistency
- A good file system guarantees good data
consistency across crashes without needing fsync() or any other
prayers (unless synchronous persistence is also required).
- On fsync()
- A useful implementation of fsync() requires a disk
access, and the application waits for it, so it slows down the
application from CPU speeds to disk speeds. If the file system
provides no data consistency guarantees and the applications
compensate for that by extensive use of fsync() (the situation that
Ted T'so strives for), the overall system will be slow because of all
these required synchronous disk accesses. With a good file system
where most applications don't need to fsync() all the time, the overall
system will be faster.
Your relational database file system is a straw man
; I hope you
had good fun beating it up.
If crashes are as irrelevant as you claim, why should anybody use
fsync()? And why are you and Ted T'so agonizing over fsync() speed? Just
turn it into a noop, and it will be fast.
to post comments)