[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d3d36051-3f7e-ffe3-6991-85614c1384b4@i2se.com>
Date: Sat, 6 Aug 2022 17:23:54 +0200
From: Stefan Wahren <stefan.wahren@...e.com>
To: Jan Kara <jack@...e.cz>
Cc: linux-ext4@...r.kernel.org, Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
Harshad Shirwadkar <harshadshirwadkar@...il.com>,
Theodore Ts'o <tytso@....edu>,
Ritesh Harjani <riteshh@...ux.ibm.com>,
linux-fsdevel@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Geetika.Moolchandani1@....com, regressions@...ts.linux.dev,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [Regression] ext4: changes to mb_optimize_scan cause issues on
Raspberry Pi
Hi,
Am 31.07.22 um 22:42 schrieb Stefan Wahren:
> Hi Jan,
>
> Am 28.07.22 um 12:00 schrieb Jan Kara:
>>
>> Also can get filesystem metadata image of your card like:
>> e2image -r <fs-device> - | gzip >/tmp/ext4-image.gz
>>
>> and put it somewhere for download? The image will contain only fs
>> metadata,
>> not data so it should be relatively small and we won't have access to
>> your
>> secrets ;). With the image we'd be able to see how the free space looks
>> like and whether it perhaps does not trigger some pathological behavior.
> i've problems with this. If i try store uncompressed the metadata of
> the second SD card partition (/dev/sdb2 = rootfs) the generated image
> file is nearly big as the whole partition. In compressed state it's 25
> MB. Is this expected?
This performance regression is also reproducible with 5.19 kernel
(arm64, defconfig) and 64-bit Raspberry Pi OS. Unfortunately the problem
with metadata generation is the same, the generated uncompressed file is
15 GB.
Powered by blists - more mailing lists