Re: abysmal performance

Am 03.05.2011 16:54, schrieb Daniel J Blueman: Hi, >>> The file the defrag ioctl works is that it schedules things for defrag >>> but doesn't force out the IO immediately unless you use -f. >>> >>> So, to test the result of the defrag, you need to either wait a bit or >>> run sync. >> >> Did so,

Re: abysmal performance

Hi, > Ok, looks like we could be doing a little better job when compression is > on to build out a bigger extent. This shouldn't be causing trouble on > an ssd at all but on your rotating disk it'll be slightly slower. > > Still most of these extents are somewhat close together, this is roughly

Re: abysmal performance

Hi, > Using compression is not a problem, but in order to reduce the maximum > amount of ram we need to uncompress an extent, we enforce a max size on > the extent. So you'll tend to have more extents, but they should be > close together on disk. > > Could you please do a filefrag -v on the file

Re: abysmal performance

Am 03.05.2011 13:00, schrieb cwillu: Hi, >> defragging btrfs does not seem to work for me. I have run the filefrag >> command over the whole fs and (manually) tried to defrag a few heavily >> fragmented files, but I don't get it to work (it still has the same >> number of extends and they are hor

Re: abysmal performance

Am 03.05.2011 13:08, schrieb Chris Mason: >> defragging btrfs does not seem to work for me. I have run the filefrag >> command over the whole fs and (manually) tried to defrag a few heavily >> fragmented files, but I don't get it to work (it still has the same >> number of extends and they are hor

Re: abysmal performance

Peter Stuge wrote: Hey, defragging btrfs does not seem to work for me. I have run the filefrag command over the whole fs and (manually) tried to defrag a few heavily fragmented files, but I don't get it to work (it still has the same number of extends and they are horrently uncorrelated) root@s

Cannot set-default back to ID 0

Hi, a recent Ubuntu upgrade killed my system. Luckily I had done a btrfs snapshot before, so I set the particular subvolume as default using # btrfs subvolume set-default 261 /mnt from a rescue system and was back up in no time. I then mounted the original volume with subvolid=0 and repaired it.