On 2013-01-31 20:08, Chris Murphy wrote:
On Jan 31, 2013, at 2:45 AM, Adam Ryczkowski <adam.ryczkowski@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx&ctz&gsessionid=OK>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
