Excerpts from John Wyzer's message of 2011-04-30 18:33:20 -0400: > Excerpts from Mitch Harder's message of Sun May 01 00:16:53 +0200 2011: > > > Hmm. > > > Tried it and it gives me about 500000 lines of > > > > > > FIBMAP: Invalid argument > > > > > > and then: > > > > > > large_file: 1 extent found > > > > > > Is that the way it is supposed to work? > > > Just asking because this was part of a vmware disk image. Both the virtual > > > machine and the rest of the host system are almost unusable once the VM > > > ist > > > started (even more unusable than without vmware :-D ) > > > > No. It sounds like the filefrag command is getting confused in the > > virtual environment. > > Misunderstanding :-) I tried filefrag _on_ a vmware disk image, not inside a > virtual machine. > The whole btrfs story here is on a real machine.
The most important files to defrag are going to be your internal firefox files (I think in .mozilla), your sup database (in .sup) and your vmware images. I would definitely suggest that you try to narrow down if vmware is making the machine seem much slower after the defrag is done. It might make sense to run the nocow ioctl on your vmware images, they are probably triggering lots of seeks. You'll notice the machine is much slower after a reboot, this is because we have to do a lot of IO to recache the extent allocation tree. If you pull from the btrfs-unstable tree, you can use mount -o space_cache, which cuts down on the reading after a reboot dramatically. If none of this works, we'll look at the files that you're fsyncing. That seems to be the bulk of your latencies. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
