| |||||||||||||
Solving the ext3 latency problemSolving the ext3 latency problemPosted Apr 18, 2009 23:22 UTC (Sat) by bojan (subscriber, #14302)In reply to: Solving the ext3 latency problem by sbergman27 Parent article: Solving the ext3 latency problem
Compare that to this comment: Fundamentally, the problem is caused by data=ordered mode. This problem can be avoided by mounting the filesystem using data=writeback or by using a filesystem that supports delayed allocation such as ext4. This is because if you have a small sqllite database which you are fsync(), and in another process you are writing a large 2 megabyte file, the 2 megabyte file wont be be allocated right away, and so the fsync operation will not force the dirty blocks of that 2 megabyte file to disk; since the blocks havent been allocated yet, there is no security issue to worry about with the previous contents of newly allocated blocks if the system were to crash at that point. Contradictory, isn't it? http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
(Log in to post comments)
Solving the ext3 latency problem Posted Apr 19, 2009 0:59 UTC (Sun) by sbergman27 (guest, #10767) [Link]
I guess.
On a related note, if he thinks that writeback is good enough for ext3 because, after all, nobody runs Linux with multiple users... then is writeback also destined to be the default for ext4? Or is the idea to destabilize the thus far rock solid ext3 enough to make ext4 look better by comparison?
Solving the ext3 latency problem Posted Apr 19, 2009 2:56 UTC (Sun) by sitaram (subscriber, #5959) [Link]
Actually, maybe not. This is not about security; as far as security goes ext4 is the same. What he is saying (or what I understand him to be saying) is that in ext4, due to delayed allocation, the performance issue with data=ordered is alleviated.
So I'd see this as "delayed allocation makes ordered almost as efficient as writeback", not "...makes writeback as secure as ordered"
|
|||||||||||||