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).
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).
there are also some email threads related to problem of metadata inline (i
don't know whether they are fixed in recent kernel):
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg16295.html
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05265.html
How about turning off inline so that btrfs works better "out of the box"?
ching
Regards,
Felix
--
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
--
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
