On Tue, 22 Mar 2011, Ted Ts'o wrote: > 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. Right, I can see your point. So maybe we should add this check to e2fsck to set the s_log_cluster_size properly if bigalloc is not set. > > - 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 > -Lukas -- 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
