From: ching <lsching17@gmail.com>
To: Felix Pepinghege <postfach@pepinghege.net>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Why btrfs inline small file by default?
Date: Wed, 31 Oct 2012 05:39:38 +0800 [thread overview]
Message-ID: <5090491A.4020306@gmail.com> (raw)
In-Reply-To: <508FC26A.1010206@pepinghege.net>
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".
next prev parent reply other threads:[~2012-10-30 21:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 11:04 Why btrfs inline small file by default? ching
2012-10-30 12:04 ` Felix Pepinghege
2012-10-30 12:17 ` cwillu
2012-10-30 21:40 ` ching
2012-10-30 22:14 ` Hugo Mills
2012-10-30 22:19 ` Hugo Mills
2012-10-30 23:47 ` ching
2012-10-31 0:12 ` David Sterba
2012-10-31 21:07 ` ching
2012-10-31 0:18 ` cwillu
2012-10-31 8:48 ` Ahmet Inan
2012-10-31 9:39 ` cwillu
2012-10-31 10:48 ` Ahmet Inan
2012-10-31 10:55 ` Michael Kjörling
2012-10-31 11:10 ` Ahmet Inan
2012-10-31 10:57 ` cwillu
2012-10-31 11:56 ` Michael Kjörling
2012-10-31 13:27 ` Ahmet Inan
2012-10-31 13:44 ` Roman Mamedov
2012-10-31 21:05 ` ching
2012-10-30 22:16 ` cwillu
2012-10-30 23:41 ` ching
2012-10-30 21:39 ` ching [this message]
2012-10-30 12:11 ` Felix Pepinghege
2012-10-30 12:13 ` Mitch Harder
2012-10-30 16:38 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5090491A.4020306@gmail.com \
--to=lsching17@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=postfach@pepinghege.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).