regression in fs/ext2.c

regression in fs/ext2.c

[Robert Millan]

The following commit:

2008-05-20  Bean  <bean123ch@gmail.com>

introduced a regression in fs/ext2.c.  The effect is that when attempting
to access an ext2 filesystem from grub-emu (and AFAICT only from grub-emu),
it will spend a lot of time (a minute or so) in a loop that calls lseek()
repeatedly (with increasingly higher offsets).

I'm sorry, I spent a while looking into this, but haven't been able to
find the source of the problem.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: regression in fs/ext2.c

[Pavel Roskin]

On Thu, 2008-06-05 at 00:12 +0200, Robert Millan wrote:
> The following commit:
> 
> 2008-05-20  Bean  <bean123ch@gmail.com>
> 
> introduced a regression in fs/ext2.c.  The effect is that when attempting
> to access an ext2 filesystem from grub-emu (and AFAICT only from grub-emu),
> it will spend a lot of time (a minute or so) in a loop that calls lseek()
> repeatedly (with increasingly higher offsets).
> 
> I'm sorry, I spent a while looking into this, but haven't been able to
> find the source of the problem.

Actually I noticed that grub won't work in qemu anymore.  I would
normally do this:

qemu -hda /dev/sda

and that would show the menu.  Sometimes the menu would be old, but
running "grub-install /dev/sda" would synchronize the cache.

In the recent days, grub would simply hang or report "out of partition".
I was installing Fedora 9 around that time, so I blamed it on qemu
changes.  But now I did a bisect in git, and sure enough, it pointed
exactly to that change from May 20.

It looks like grub has problems accessing mounted filesystem.  That's a
problem because the OS can reboot suddenly, leaving the filesystem in a
state that grub cannot grok.

I'm using ext3 everywhere, so I suspect that the problem may have to do
with the journal support implemented in that commit.

-- 
Regards,
Pavel Roskin

Re: regression in fs/ext2.c

[Bean]

On Thu, Jun 5, 2008 at 6:38 AM, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2008-06-05 at 00:12 +0200, Robert Millan wrote:
>> The following commit:
>>
>> 2008-05-20  Bean  <bean123ch@gmail.com>
>>
>> introduced a regression in fs/ext2.c.  The effect is that when attempting
>> to access an ext2 filesystem from grub-emu (and AFAICT only from grub-emu),
>> it will spend a lot of time (a minute or so) in a loop that calls lseek()
>> repeatedly (with increasingly higher offsets).
>>
>> I'm sorry, I spent a while looking into this, but haven't been able to
>> find the source of the problem.
>
> Actually I noticed that grub won't work in qemu anymore.  I would
> normally do this:
>
> qemu -hda /dev/sda
>
> and that would show the menu.  Sometimes the menu would be old, but
> running "grub-install /dev/sda" would synchronize the cache.
>
> In the recent days, grub would simply hang or report "out of partition".
> I was installing Fedora 9 around that time, so I blamed it on qemu
> changes.  But now I did a bisect in git, and sure enough, it pointed
> exactly to that change from May 20.
>
> It looks like grub has problems accessing mounted filesystem.  That's a
> problem because the OS can reboot suddenly, leaving the filesystem in a
> state that grub cannot grok.
>
> I'm using ext3 everywhere, so I suspect that the problem may have to do
> with the journal support implemented in that commit.

Hi,

I believe it's the new journal support for ext2 that cause the
problem. Can you create a small disk image for me to test ?

-- 
Bean