Re: [PATCH v4 3/3] squashfs: implement readahead

[Matthew Wilcox <willy@infradead.org>]

On Fri, Jun 03, 2022 at 02:54:21PM +0200, Marek Szyprowski wrote:
> Hi,
> 
> On 01.06.2022 12:39, Hsin-Yi Wang wrote:
> > Implement readahead callback for squashfs. It will read datablocks
> > which cover pages in readahead request. For a few cases it will
> > not mark page as uptodate, including:
> > - file end is 0.
> > - zero filled blocks.
> > - current batch of pages isn't in the same datablock or not enough in a
> >    datablock.
> > - decompressor error.
> > Otherwise pages will be marked as uptodate. The unhandled pages will be
> > updated by readpage later.
> >
> > Suggested-by: Matthew Wilcox <willy@infradead.org>
> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > Reported-by: Matthew Wilcox <willy@infradead.org>
> > Reported-by: Phillip Lougher <phillip@squashfs.org.uk>
> > Reported-by: Xiongwei Song <Xiongwei.Song@windriver.com>
> > ---
> 
> This patch landed recently in linux-next as commit 95f7a26191de 
> ("squashfs: implement readahead"). I've noticed that it causes serious 
> issues on my test systems (various ARM 32bit and 64bit based boards). 
> The easiest way to observe is udev timeout 'waiting for /dev to be fully 
> populated' and prolonged booting time. I'm using squashfs for deploying 
> kernel modules via initrd. Reverting aeefca9dfae7 & 95f7a26191deon on 
> top of the next-20220603 fixes the issue.

How large are these files?  Just a few kilobytes?