On 2018年03月06日 19:58, David Sterba wrote: > On Fri, Mar 02, 2018 at 07:40:14PM +0800, Qu Wenruo wrote: >> On 2018年03月02日 19:00, Filipe Manana wrote: >>> On Fri, Mar 2, 2018 at 10:54 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >>>> On 2018年03月02日 18:46, Filipe Manana wrote: >>>>> On Fri, Mar 2, 2018 at 5:22 AM, Qu Wenruo <w...@suse.com> wrote: >>>>>> Normally when specifying max_inline, we should normally limit it by >>>>>> uncompressed extent size, as it's the only thing user can control. >>>>> >>>>> Why does it matter that users can control it? Will they write less (or >>>>> more) data to files because stuff won't get inlined? >>>>> Why do they care about stuff getting inlined or not? That's an >>>>> implementation detail of btrfs to speed up access to file data and >>>>> save some space. >>>> >>>> Then why we still have max_inline mount option? >>> >>> My comment was about deciding based on which size to make the decision >>> (compressed vs uncompressed). >> >> The same thing, we have given user options to trigger the behavior, then >> we should give them *predictable* option to modify the behavior. >> >> Not something confusing like current max_inline. >> >> Either we give user max_inline and max_inline_compressed, or both follow >> max_inline. > > I agree with Filipe and don't see a reason to limit the inlining > capabilities. Max inline exists to set the maximum file size that will > be considered for inlining, the rest is implementation detail. > > In a similar way the compression can decide if the data will be > compressed, though the user has specified the mount option. > > Adding another option (max_inline_compressed) does not necessarily > improve the situation. This requires the user to understand the values > it can have and how it interacts with other options. > > I've been thinking about this patchset for a few days and still don't > think there's a problem we need to fix. We can certainly improve the > reporting, so the mount option value will be adjusted to the exact > inline limit and then printed to syslog. Additionally we can export the > value as sysfs file, and udate documentation.
Fine, I will discard this patch and just enhance the prompt. Thanks, Qu > -- > 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 >
signature.asc
Description: OpenPGP digital signature
