On Mon, Mar 21, 2011 at 08:35:20PM +0100, Lukas Czerner wrote: > > Maybe this is a bit nitpicky, but should not this be rather done in > separate commit as it has nothing to do with bigalloc ? Perhaps. The reason why I had it was because I wanted to see the blocks per group information when I was testing a read-only bigalloc mount. I'll grant this is tenuous; I suppose I could separate out these two patch hunks into a separate patch, but I didn't think it was really worth it. > > I wonder if we should continue at this point, because something > definitely went wrong as it has not biballoc feature but yet > s_log_cluster_size does not match s_log_block_size which means > definitely corruption or an error somewhere. I considered this, but I was just paranoid because I didn't want to change anything in the !bigalloc case. There was one or two users who reported that somehow the second 512 byte sector was containing garbage, and nothing had cared in the past, but when we first broke into the second 512 bytes of the superblock we did have some complaints, so that's why I decided to err on the side of conservatism. - 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
