On Fri, Jun 24, 2011 at 4:28 AM, Kazuya Mio <k-mio@xxxxxxxxxxxxx> wrote: > Hi Greg, > I'm sorry for the late reply. > > 2011/06/23 20:16, Greg Freemyer wrote: >> >> For a sparse file, can you explain why you treat the head and tail >> extents of a block group differently? > > Could you tell me what "block group" you said means? Kazuya, Sorry if I've got the terminology wrong. I'm talking about sparse files. Where you might have: block_group1 - hole - block_group2 - hole - block_group3. Block_group2 has a head and a tail extent. In my mind, from a performance perspective, they are symmetric. Meaning that having a small extent at the beginning is no better and no worse than having a small extent at the end. > If "block group" means the ext4 block group, I will treat the head and tail > extents of a block group the same way. > > And if "block group" means the chunk of the extents whose offset is > continued, > I will treat only the tail extents as a special case. > > # filefrag -v /mnt/mp1/file > Filesystem type is: ef53 > File size of /mnt/mp1/file is 285212672 (69632 blocks, blocksize 4096) > ext logical physical expected length flags > 0 0 34816 30720 > 1 30720 65536 2048 unwritten > 2 65536 67584 4096 unwritten,eof > /mnt/mp1/file: 1 extent found > > The case is not fragmented. The length of #1 extent is a little bit short, > but there is no point in doing defragmentation because of the hole > existence. Please consider this caseL Assume for a minute a large sparse file with lots of holes. This is one like a VM might create. And that in the middle of the file is a block_group with a hole in front of it and a hole after it. Assume it is 1 extent long exactly, and that one extent is a maximum extent (ie 128 MB with 4KB blocks I believe). Now assume the VM writes a single short extent at the end of block_group. Your logic says full_extent+small_extent, no need to defrag because its already optimal. I agree with that. Now assume instead of the block_group being extended at the tail, it is extended at the head. Now you have: small_extent+full_extent Your logic as I understand it will score that as not as good as the first case. I disagree, Both are optimally defragged and both should get the same score. > > Regards, > Kazuya Mio Greg -- 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
