[U-Boot] [PATCH] [RFC] blk: Increase cache element size

[Tom Rini]

On Wed, Aug 15, 2018 at 06:20:16PM +0200, Marek Vasut wrote:
> On 08/15/2018 06:12 PM, Tom Rini wrote:
> > On Wed, Aug 15, 2018 at 06:04:50PM +0200, Marek Vasut wrote:
> > 
> >> On 08/15/2018 04:30 PM, Tom Rini wrote:
> >>> On Wed, Aug 08, 2018 at 01:20:29PM +0200, Marek Vasut wrote:
> >>>
> >>>> Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet
> >>>> the underlying block layer devices usually report support for 512B . In
> >>>> most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks
> >>>> etc.) and the real block size of those devices is much bigger.
> >>>>
> >>>> To avoid performance degradation with such devices and FS setup, bump
> >>>> the maximum cache entry size to 4 kiB.
> >>>>
> >>>> Signed-off-by: Marek Vasut <marex at denx.de>
> >>>> Cc: Tom Rini <trini at konsulko.com>
> >>>> Cc: Simon Glass <sjg at chromium.org>
> >>>
> >>> Reviewed-by: Tom Rini <trini at konsulko.com>
> >>>
> >>> I'll pick this up post v2018.09 if no one objects, thanks!
> >>
> >> I object. I was hoping there'd be some discussion on how to solve this
> >> in a future-proof manner ... it's only a matter of time until someone
> >> uses ext4 with 8k blocks on an SSD ...
> > 
> > In general, sure?  In specific, mkfs.ext4 1.42.13 man page says 1/2/4KiB
> > are the only valid values of block size, and based on having to whack
> > this for some other projects it's pretty common for OpenEmbedded at
> > least to spit out 1KiB block size images.
> 
> OE spits 4k , that's how I triggered it,
> meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext2 ?= "-i 4096"
> meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext3 ?= "-i 4096"
> meta/classes/image_types.bbclass:EXTRA_IMAGECMD_ext4 ?= "-i 4096"

That's bytes-per-inode, I was referring to block size which is -b and
dynamic unless specified.

> > So unless you know of cases
> > today (or tomorrow, but not next year) where 8KiB is common or likely,
> > we should probably just bump this for now and maybe make it a tunable so
> > it's easily changed?
> 
> It is already tunable, see blkcache config in blkcache command.
> 
> But what I'd like to see is somehow the FS and the underlying storage
> negotiating the best settings. Can we get the FS block size from the
> block cache perspective ?

Good questions that I don't have an answer to.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180815/61c269cb/attachment.sig>