On 10/31/2012 06:19 AM, Hugo Mills wrote: > On Tue, Oct 30, 2012 at 10:14:12PM +0000, Hugo Mills wrote: >> On Wed, Oct 31, 2012 at 05:40:25AM +0800, ching wrote: >>> On 10/30/2012 08:17 PM, cwillu wrote: >>>>>> 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). >>>> As I understand it, in basically all cases the total storage used by >>>> inlining will be _smaller_, as the allocation doesn't need to be >>>> aligned to the sector size. >>>> >>> if i have 10G small files in total, then it will consume 20G by default. >> If those small files are each 128 bytes in size, then you have >> approximately 80 million of them, and they'd take up 80 million pages, >> or 320 GiB of total disk space. > Sorry, to make that clear -- I meant if they were stored in Data. > If they're inlined in metadata, then they'll take approximately 20 GiB > as you claim, which is a lot less than the 320 GiB they'd be if > they're not. > > Hugo. >
is it the same for: 1. 3k per file with leaf size=4K 2. 60k per file with leaf size=64k -- 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
