On 27/08/2021 08:38, Qu Wenruo wrote:

On 2021/8/27 上午1:53, David Sterba wrote:

quoted

On Tue, Aug 24, 2021 at 01:54:21PM +0800, Anand Jain wrote:

quoted

On 16/08/2021 23:10, David Sterba wrote:

quoted

On Tue, Aug 10, 2021 at 11:23:44PM +0800, Anand Jain wrote:

quoted

The mount option max_inline ranges from 0 to the sectorsize (which is
equal to pagesize). But we parse the mount options too early and 
before
the sectorsize is a cache from the superblock. So the upper limit of
max_inline is unaware of the actual sectorsize. And is limited by the
temporary sectorsize 4096 (as below), even on a system where the 
default
sectorsize is 64K.

quoted

So the question is what's a sensible value for >4K sectors, which is 
64K
in this case.

Generally we allow setting values that may make sense only for some
limited usecase and leave it up to the user to decide.

The inline files reduce the slack space and on 64K sectors it could be
more noticeable than on 4K sectors. It's a trade off as the inline data
are stored in metadata blocks that are considered more precious.

Do you have any analysis of file size distribution on 64K systems for
some normal use case like roo partition?

I think this is worth fixing so to be in line with constraints we have
for 4K sectors but some numbers would be good too.

Default max_inline for sectorsize=64K is an interesting topic and
probably long. If time permits, I will look into it.
Furthermore, we need test cases and a repo that can hold it (and
also add  read_policy test cases there).

IMO there is no need to hold this patch in search of optimum default
max_inline for 64K systems.

Yeah, I'm more interested in some reasonable value, now the default is
2048 but probably it should be sectorsize/2 in general.

Half of sectorsize is pretty solid to me.

But I'm afraid this is a little too late, especially considering we're
moving to 4K sectorsize as default for all page sizes.

I am writing a patch to autotune it to sectorsize/2 by default.

To test this, we need to have a filesystem with file sizes of various
sizes (so that we have both inline and regular extents) and run rw. It
looks like no regular workload (fio/sysbench) can do that and, I am
stuck on that. Any inputs?

quoted

quoted

quoted

Please fix/reformat/improve any comments that are in moved code.

   I think you are pointing to s/f/F and 80 chars long? Will fix.

Yes, already fixed in the committed version in misc-next, thanks.

  Thanks.

- Anand