On Tue, 2010-06-01 at 09:50 -0400, Martin K. Petersen wrote: > >>>>> "James" == James Bottomley <James.Bottomley@xxxxxxx> writes: > > James> Would it be too much work in the fs to mark the page dirty before > James> you begin altering it (and again after you finish, just in case > James> some cleaner noticed and initiated a write)? Or some other flag > James> that indicates page under modification? All the process > James> controlling the writeout (which is pretty high up in the stack) > James> needs to know is if we triggered the check error by altering the > James> page while it was in flight. > > James> I agree that a block based retry would close all the holes ... it > James> just doesn't look elegant to me that the fs will already be > James> repeating the I/O if it changed the page and so will block. > > I experimented with this approach a while back. However, I quickly got > into a situation where frequently updated blocks never made it to disk > because the page was constantly being updated. And all writes failed > with a guard tag error. But that's unfixable with a retry based system as well if the page is changing so fast that the guard is always wrong by the time we get to the array. The only way to fix this is either to copy or freeze the page. James -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
