Qu Wenruo posted on Mon, 12 Jan 2015 10:32:30 +0800 as excerpted: > [New layout] > Take leafsize as 4K for example. > > Sectors: > |---0---|---1---|---2---|---3---|---4---|---5---|---6---|---7---| > Sector 0: Csum of the leaf/node (32~4K)(not changed) > Sector 1: Csum of the first eighths of the leaf/node (32~512) > Sector 2: Csum of the second eighths of the leaf/node (512~1024) > .... > Sector 7: Csum of the last eighths of the leaf/node (3584 ~ 4096) OK, I've been up too long and should be sleeping, and it may be that's affecting my logic, but AFAICT either you're missing something obvious, or I am. There are eight eights, and eight "sectors", but the first one is already used, thus leaving seven available. You have the first eighth (ending at byte 512*1) in sector one (zero-based so the second sector), the second (ending at byte 512*2=1024) in sector two... the last (eighth) eighth (ending at byte 512*8=4096) in sector seven. Of eighths 3-7 in that ..., which eighth do you skip csumming, or is one of them a full quarter instead of an eighth? Of course if we could make them sevenths... But making it four quarters instead of 7/8 is perhaps more reasonable, with the remaining three sectors remaining unused, and if only one fails csum we still save 75% of the leaf/node, instead of none of it, currently. But maybe it makes complete sense as-is and I should be sleeping instead of trying to make sense of what is clearly not making sense to me at this point... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
