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. -- 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
