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