Solving the ext3 latency problem [LWN.net]

Solving the ext3 latency problem

Posted Apr 14, 2009 16:56 UTC (Tue) by nye (guest, #51576)
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? The special-casing for rename means that renames should have the same behaviour, and data=guarded appears to mean that resizes have the same behaviour (or does it mean that both data and metadata can now be further delayed than data=ordered?).

IIUC, I suppose there could be things like *new* files being created with zero size after a crash, rather than not being created at all, which doesn't seem like the end of the world. I admit I haven't actually thought this through very much at all yet, so that could be nonsense for both behaviours. :P

What other reliability/data integrity implications would this have?

to post comments

Solving the ext3 latency problem

Posted Apr 14, 2009 18:09 UTC (Tue) by corbet (editor, #1) [Link] (2 responses)

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.

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.