Re: Poor performance of btrfs. Suspected unidentified btrfs housekeeping process which writes a lot

[Adam Ryczkowski <adam.ryczkowski@statystyka.net>]

On 2013-01-31 20:08, Chris Murphy wrote:
> On Jan 31, 2013, at 2:45 AM, Adam Ryczkowski <adam.ryczkowski@statystyka.net> wrote:
>> Yes, you are right. It is important contributing factor, why relatime mount option killed my performance so badly.
> So is this what was causing the problem?
Yes.
>> Can you tell me more? Because I have only learned, that btrfs multi-device support cannot join two volumes without striping. And striping in this case is equivalent to fragmentation, which we want to avoid. In contrast to what LVM can do. LVM can concatenate the underlying storage together, without striping.
> When you create a btrfs file system, by default the data profile is single, and metadata profile is dup. When you add another device to the volume, it stays this way. The single data profile behaves similar to LVM linear, except btrfs will alternate chunk allocations between devices, so that one isn't just sitting there spinning for a month and not being used at all.
>
> So it's not striping. But even if it were striping, that would help you on write performance in particular because now it's effectively RAID 60. I don't see why striping is considered fragmentation.
Well, if the devices are on the same physical hard-drive, than 
sequential file reading would cause hard drive heads to seek between the 
first and the other partition on every extent. This is something 
equivalent to defragmentation; it is only good if the partitions are on 
separate hard drives.
> To change the profile for the volume, you use -dconvert and/or -mconvert with a rebalance operation.
Once again, thank you very much, Chris.
-- 

Adam Ryczkowski
+48505919892 <callto:+48505919892>
Skype:sisteczko 
<skype:sisteczko><https://www.google.com/calendar/b/0/embed?src=adam.ryczkowski@statystyka.net&ctz&gsessionid=OK>