On Sat, Oct 20, 2007 at 12:39:33PM +0900, Tetsuo Handa wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html