On Sun, Feb 24, 2013 at 04:46:30AM +0000, Tony Lu wrote: > >> For example, if xlog_bread_noalign() wants to read blocks from #1 > >> to # 9, in which case the passed parameter blk_no is 1, and nbblks > >> is 8, sectBBsize is 8, after the round down and round up > >> operations, we get blk_no as 0, and nbblks as still 8. We > >> definitely lose the last block of the log data. > > > >Yes, I fully understand that. But I also understand how the log > >works and that this behaviour *should not happen*. That's why > >I'm asking questions about what the problem you are trying to fix. > > I am not sure about this, since I saw many reads on > non-sector-align blocks even when successfully mounting good XFS > partitions. I didn't say that non-sector align reads should not be attempted by log recovery - it's obvious from the on disk format of the log that we have to parse it in chunks of 512 bytes to make sense of it's contents, and that leads to the 512 byte reads and other subsequent unaligned reads. *However* Seeing that there are unaligned reads occurring does not mean that the structures in the log should be unaligned. Your test output indicated a log record header at an unaligned block address, and that's incorrect. It doesn't matter what the rest of the log recovery code does with non-aligned IO - the fact is that your debug implies that the contents of the log is corrupt and that implies a deeper problem.... > And also there is code in xlog_write_log_records() which handles > non-sector-align reads and writes. Yes, it does handle it, but that doesn't mean that it is correct to pass unaligned block ranges to it. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
