On Tue, Feb 19, 2008 at 04:40:32AM -0700, Andreas Dilger wrote: > > No, it hasn't always been true that we cleared the _hi fields in the > kernel code. But, it has been a year or more since we found this bug, > and all CFS e2fsprogs releases since then have cleared the _hi fields, > and there has not been any other e2fsprogs that supports extents, so > we expect that there are no filesystems left in the field with this > issue, and even then the current code will prefer to clear the _hi > bits instead of considering the whole extent corrupt. > I checked again, and it looks like the interim code is indeed clearing the _hi bits. I managed to confuse myself into thinking it didn't for index nodes, but I checked again and it seems to be doing the right thing. The reason why I asked is that the extents code in the 'next' branch of e2fsprogs *does* consider the whole extent to be corrupt, since in the long run once we start 64-bit block number extent blocks, if the physical block number (including the high 16 bits) is greater than s_blocks_count, simply masking off the high 16 bits of the 48 bit extent block is probably not the right way of dealing with the problem. I think that's probably a safe thing to do since all of your customers who might have had a filesystem with non-zero _hi fields have almost certainly run e2fsck to clear the _hi bits at least once; do you concur that is a safe assumption? Or would you prefer that I add some code that tries to clear just the _hi bits, perhaps controlled by a configuration flag in e2fsck.conf? Regards, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
