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