On 01/22/2011 08:37 PM, Theodore Tso wrote:
On Jan 22, 2011, at 11:21 AM, torn5 wrote:
Is the fsync in a nobarrier mount totally swallowed?
No. It will still cause a journal commit, and send disk writes down to the HDD. How those disk writes will be interpreted by the HDD is completely up to the HDD's firmware.
...
If not:
a) what guarantees does it provide in a nobarrier situation and
As long as there is not a power failure (or disk failure, of couse), those disk writes will eventually hit the platter. ....
VERY interesting
thanks for the explanation
b) is there a "fakefsync" mount option or some other way to make it a no-op? (I understand the risk, and the fact that this is actually a change in the application's logic)
No, sorry. Usually the fsync is there for a good reason, and if fsync's are completely eliminated, you have absolutely no guarantees at all. (Kernel panics, reset buttons, etc., all will cause the database to be totally scrambled.) Providing such a knob to system administrators who might use it to "speed up" their application, is considered a bit of an attractive nuisance
Sometimes it's useful, and that's the reason why Postgresql and Mysql
both have a no-fsync mode.
Sometimes you have to do something for which intermediate state doesn't
matter. Think at it as a computation: if it fails, you restart it from
the beginning. In scientific research this is often the case. Often to
save time you use software already written, which might have an
excessively conservative behaviour for a "computation" , and this slows
down your computation. But rewriting such application is simply too
much, so you end up waiting patiently... that's why a fakefsync mount
option would be nice to have.
Anyway, you said fsyncs in nobarriers mode (only?) generate a journal
commit and push writes to the HDD.
Then if I also disable the journal the only thing that remains is the
push of data to the HDD, right?
This is near to a no-op I would say because data should have gone to the
disks earlier or later... Ow... oh no, it's not, because you wait for
the disk to return a completion and in the meanwhile you cannot use the
CPU. Right? Ok so for a single threaded app there is indeed difference.
May I ask how is this "push of data to the disk" implemented: does it
skip the request queue for the disk (i.e. jumps ahead of the queue), or
has other kinds of special priority, or it is submitted to the tail like
normal and the fysnc waits patiently for it to reach the disk?
Thank you for all these explanations
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
