On 2011-06-10, at 11:14 AM, Phillip Susi wrote: > On 6/10/2011 12:19 PM, Andreas Dilger wrote: >> I think in the presence of flex_bg this issue is moot. > > What is the issue without flex_bg? No "issue" really, just that the block/inode bitmaps are spread all over the filesystem. The original discussion was about whether there could be "larger bitmaps that addressed more than 32768 blocks", which is essentially what the flex_bg feature provides. With flex_bg the bitmaps for different groups will be allocated adjacent to each other on disk, and allow addressing more than 32768 blocks without any seeking. On large filesystems without flex_bg, the distribution of the bitmaps without flex_bg means that a seek is needed to read each one, and given that spinning disks have stayed at about 100 seeks/sec for decades it means 10+ minutes just to read all of the bitmaps. On my 2TB 5400 RPM SATA drive, e2fsck time went from ~20 minutes to ~3 minutes by copying the data to a new ext4 filesystem with flex_bg + extents. For a fair comparison, I then reformatted the original (identical) disk without flex_bg or extents and copied the data back, so that there wasn't any unfair comparison between the newly-formatted filesystem and the old fragmented one. Cheers, Andreas -- 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
