On 10/30/2012 08:04 PM, Felix Pepinghege wrote:
> Hi ching!
>
> Am 30.10.2012 12:04, schrieb ching:
>> Hi all,
>>
>> I am testing my btrfs root partition with "max_inline=0", and 64k leaf size 
>> for weeks and it seems that it is fine.
>>
>>
>> AFAIK btrfs inline small files into metadata by default, I am curious why?
>>
>> If there is only a few small files, then there will be neither effect nor 
>> benefit at all
>
> I disagree in this point. There will be a (probably huge) benefit in terms of 
> performance. If the file data is inlined, you have a good chance (especially 
> with large leaf sizes, although even then it is not guaranteed) that the data 
> is in the same leaf as the inode element. So you already have the file data 
> as you always access complete leafs. If you would store the data in extents, 
> you would need to read the respective extent, which can be anywhere on the 
> disk. That is, you most likely need to move the head. This brings overhead 
> (especially with small files, as the reading process is relatively fast 
> compared to the time you need to position the head).

You may be correct.

But I doubt inline data may bring possible performance benefit, bigger metadata 
always means more trouble for concurrency/performance and cache miss ratio

>
>> If there is a lot of small files, then the size of metadata will be 
>> undesirable due to deduplication
>
> Yes, that is a fact, but if that really matters depends on the use-case 
> (e.g., the small files to large files ratio, ...). But as btrfs is designed 
> explicitly as a general purpose file system, you usually want the good 
> performance instead of the better disk-usage (especially as disk space isn't 
> expensive anymore).

Yes, but as a general purpose filesystem, i guess that the default behaviour 
should be "safe"?

Not many user is patient enough to troubleshoot metadata "explosion".
--
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

Reply via email to