Re: [PATCH] Bug fix for LVM

[Bean]

On Sun, Jul 19, 2009 at 4:05 AM, Robert Millan<address@hidden> wrote:
> On Sat, Jul 18, 2009 at 09:59:55PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> On Sat, Jul 18, 2009 at 9:43 PM, Bean<address@hidden> wrote:
>> > On Sun, Jul 19, 2009 at 3:11 AM, Robert Millan<address@hidden> wrote:
>> >> On Sat, Jul 18, 2009 at 10:11:19PM +0800, Bean wrote:
>> >>>      }
>> >>>
>> >>>    grub_raid_rescan ();
>> >>> +  grub_lvm_fini ();
>> >>> +  grub_lvm_init ();
>> >>
>> >> This is aside from this patch, but I don't see the purpose of this
>> >> grub_raid_rescan() function.  It's in raid.mod but only used by
>> >> grub-fstest, so at least it should be #ifdef'ed out, but looking at
>> >> what it does, it seems very ad-hoc.  It basically amounts to the
>> >> same you're doing with grub_lvm_fini() and grub_lvm_init().  Could
>> >> you fix this while at it?
>> >
>> > This is required. As raid and lvm scan device in init function, but
>> > grub-fstest uses loopback device, which hasn't been setup in
>> > grub_init_all. This code rescan raid and lvm, otherwise there won't be
>> > available.
>> >
>> This situation isn't strictly speaking restricted to grub-fstest then.
>> One would sensibly want to loopmount lvm image in grub shell. Is there
>> a way to do it cleanly?
>
> I think a good long-term solution is to move the scan function from
> grub_raid_init() to wheereever appropiate to make the scan happen
> dynamically everytime e.g. the iterate() function is called.  However,
> doing this efficiently needs some work.

Hi,

I've come up an alternative solution to grub_raid_rescan, we can use
the same trick as lvm, call fini and then init function, this would
have the same effect of rescanning. Now that grub_raid_rescan is gone,
I can simply raid.c further by moving grub_raid_scan_device into
grub_raid_register.

As for dynamically scanning, I think it's not common to mount lvm/raid
in loopback files, we could just ignore it for now.

-- 
Bean

lvm_2.diff
Description: Text Data