On Sat, Oct 20, 2007 at 12:39:33PM +0900, Tetsuo Handa wrote: > Theodore Tso wrote: > > beginning of every single block group. You have a small number of > > files on your system (349) occupying an average of 348 megabytes. So > > it's not at all surprising that the contiguous percentage is 32%. > I see, thank you. Yes, there are many files splitted in 2GB each. > > But what is surprising for me is that I have to wait for more than > five minutes to save/restore the virtual machine's 512MB-RAM image > (usually it takes less than five seconds). > Hdparm reports DMA is on and e2fsck reports no errors, > so I thought it is severely fragmented. > May be I should backup all virtual machine's data and > format the partition and restore them. Well, that's a little drastic if you're not sure what is going on is fragmentation. 5 minutes to save/restore a 512MB ram image, assuming that you are saving somewhere around 576 megs of data, means you are writing less than 2 megs/second. That seems point to something fundamentally wrong, far worse than can be explained by fragmentation. First of all, what does the "filefrag" program (shipped as part of e2fsprogs, not included in some distributions) say if you run it as root on your VM data file? Secondly, what results do you get when you run the command "hdparm -tT /dev/sda" (or /dev/hda if you are using an IDE disk)? This kind of performance regression is the sort of thing I see on my laptop when compile the kernel with the wrong options, and/or disable AHCI mode in favor of compatibility mode, such that my laptop SATA performance (as measured using hdparm) drops from 50 megs/second to 2 megs/second. Regards, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
