| |||||||||||
Barriers and journaling filesystemsBarriers and journaling filesystemsPosted May 24, 2008 19:50 UTC (Sat) by giraffedata (subscriber, #1954)Parent article: Barriers and journaling filesystems
Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. I don't see how that's true even usually. Even a classic elevator algorithm sweeps backward as well as forward. And if I were a disk drive with multiple blocks to write on the same track, I would not wait for the lowest numbered block to come around and write the track in order; I'd start writing whatever is under the head right now.
(Log in to post comments)
Barriers and journaling filesystems Posted May 24, 2008 23:40 UTC (Sat) by dlang (subscriber, #313) [Link] but on modern disks you really don't know where the borders of a track are. it's really just an array of blocks
Barriers and journaling filesystems Posted May 25, 2008 2:47 UTC (Sun) by giraffedata (subscriber, #1954) [Link] but on modern disks you really don't know where the borders of a track are. it's really just an array of blocks I don't know what "but" refers to here; I made a statement about "if I were a disk drive," and the disk drive definitely knows where the borders of the tracks are. And though I have no actual evidence of it, I would be very surprised if the disk drive did not use that knowledge to optimize performance. The idea suggested in the article that ext3 tends to get ordered writes (to the platters) because it usually does journal updates in logical block number order seems to assume that the disk drive does writes from cache to platter in logical block number order. I can't believe that it would do that, even usually, because it would be so much slower than optimum.
Barriers and journaling filesystems Posted May 25, 2008 3:27 UTC (Sun) by dlang (subscriber, #313) [Link] the drive will write an entire track at a time (they have done so for years) but you have no way of knowing if the journal that you allocated spans a track boundry (since you don't know where the boundry is), and you also don't know if the drive has re-allocated any blocks to avoid bad spots on the disk in the middle of your journal. either one of these will destroy the atomic nature of writes to the journal
Barriers and journaling filesystems Posted May 25, 2008 6:40 UTC (Sun) by giraffedata (subscriber, #1954) [Link] Whether it writes the whole track doesn't matter. It's the order in which it writes the blocks. Does it wait for the beginning of the track to come around and write from start to finish (average time - 1.5 revolutions)? Or does it write starting now (average time 1 revolution)? I presume it's the latter.Nobody's said anything about ext3 knowing where the blocks are physically, so I don't know why you bring that up. The article just says ext3 updates the journal in logical block number order and suggests that means they tend to go the platter in the same order. And I've been saying I don't believe that.
Barriers and journaling filesystems Posted May 25, 2008 10:53 UTC (Sun) by dlang (subscriber, #313) [Link] I misunderstood what you were saying. I thought that you were saying that if the entire journal was on the same track it would get written all at once, even if it wrapped over the end of the journal.
|
|||||||||||