Andreas Dilger wrote: > On Sep 15, 2007 22:46 -0500, Eric Sandeen wrote: >> * calculate the minimum rec_len when generating the map, vs. >> just storing the current rec_len. > > Well, we already do this when moving the entries, so in theory we > should do it when checking how many entries to move. That said, > we know we can't _increase_ the amount of space used (so no chance > of introducing a problem) but we might still end up with some imbalance. I think I'm going to pass on this, at least for now, to save the extra calculation. We've lived for years with whatever split the original code gave us, and with the exception of this overflow, we've not seen problems. Splitting based on rec_len (vs. EXT3_DIR_REC_LEN) should still split things fairly well, on average. If we used EXT3_DIR_REC_LEN)(name_len) for the new tests, I think we'd first need to add up the minimal size of *all* entries, because the new threshold would no longer be blocksize/2. So, this would be more times around the loop. If anyone feels strongly that we should make this split as accurate as possible, I'm willing to patch that up too, but for now I think I'd like to get the more targeted fix in place, as it should solve the bug at hand in a simpler manner. Sound ok? -Eric - 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
