> >>That is way complicated, I was just going to take two devices, one that's a > >>linear mapping and the other that's the log, and then write to the log the > >>sector+data that was written in order that it completes, and then have > >>userspace do the replay. So basically do the flush tracking like I am, then > >>write out chunks to the log device to keep a semblance of how the flushing > >>would have affected stuff, something like this > >> > >>write a, write b, a complete, flush, b complete, flush complete > >> > >>would log out > >> > >>wrote a, flush, write b, <other writes>, <next flush> > >> > >>and then we have a userspace thing that could do something like replay all > >>writes to a flush, do fs consistency and data consistency checks, walk to > >>the next flush, rinse repeat, and that way we could be sure that we always > >>have a consistent fs. > > > >I guess that'd be an ok start, but I don't think you need any clever > >kernel code to do that. I've hacked up something like this in bash with > >blktrace, loopback files, and dd :/. > > I don't think blktrace gives us the data being written though does it? If it > does then hooray I'm done playing a device mapper developer. Right, that script was only working with the dumb simple case of using manual double buffering and simple test loads that wouldn't overwrite blocks. > With the logging approach then it is completely up to us how we replay the > log, so we can always go back and do more horrible things with the replay, > like replay for a while, skip a flush and write some of the next random crap > and see what happens. Doing horrible things is awesome and that is what I > want, but I also want to make sure we're not failing in the simple things > too. Thanks, Sure, that's fair. So maybe expand blktrace to include the data payloads? :). - z -- 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
