| |||||||||||||
Solving the ext3 latency problemSolving the ext3 latency problemPosted Apr 14, 2009 18:09 UTC (Tue) by corbet (editor, #1)In reply to: Solving the ext3 latency problem by nye Parent article: Solving the ext3 latency problem
data=guarded sounds rather interesting, but I'm not sure I understand how it differs from data=ordered. In what situations could the result be different? data=ordered forces all data to go out before the metadata is written; in practice, that forces data to be written within five seconds. data=guarded, as I understand it, delays the writing of certain metadata (the file size in particular) until the data has been written. The timing is looser, but it still keeps random junk from showing up within a file after a crash.
(Log in to post comments)
Solving the ext3 latency problem Posted Apr 14, 2009 18:51 UTC (Tue) by masoncl (subscriber, #47138) [Link]
Right, data=guarded delays pushing the new file size down to disk until the data is there first.
It still does the old style data=ordered in cases where the file size isn't enough protection (like filling holes).
Solving the ext3 latency problem Posted Apr 16, 2009 15:28 UTC (Thu) by sandeen (guest, #42852) [Link]
Also, in practice (and as evidenced by my testing), data=guarded will leave you with smaller file sizes (potentially 0-length) when you crash. But that is better than having garbage (potentially other people's data) in those files.
The rename & truncate hacks will help flush some data, but if you, say, untar a kernel tree and crash, those hacks don't come into play.
data=writeback would wind up garbage in the files, data=guarded would wind up with 0-length or shortened files with no garbage, and data=ordered would likely have more files intact due to the journal transaction commits causing more flushing along the way... and no garbage.
|
|||||||||||||