Support for reading LVM volumes

Support for reading LVM volumes

[Jeroen Dekkers]

Hi all,

I've just commited the code for reading LVM volumes. The only issue
that I know of is that it currently doesn't support reading snapshot
volumes. All the normal LVM volumes (striped and linear) are supported
however.

I'm going to work on adding support for LVM to grub-setup now. That's
the last remaining thing in my SoC project.

Jeroen Dekkers

Re: Support for reading LVM volumes

[Hollis Blanchard]

On Sun, 2006-08-13 at 17:13 +0200, Jeroen Dekkers wrote:
> I've just commited the code for reading LVM volumes. The only issue
> that I know of is that it currently doesn't support reading snapshot
> volumes. All the normal LVM volumes (striped and linear) are supported
> however.

Very nice. :)

> I'm going to work on adding support for LVM to grub-setup now. That's
> the last remaining thing in my SoC project.

What will happen to the google-soc2006 CVS branch when you're done?

-Hollis

Re: Support for reading LVM volumes

[Jeroen Dekkers]

At Sun, 13 Aug 2006 11:49:06 -0500,
Hollis Blanchard wrote:
> 
> What will happen to the google-soc2006 CVS branch when you're done?

It should be merged into the mainline.

Jeroen Dekkers

Re: Support for reading LVM volumes

[Hollis Blanchard]

On Sun, 2006-08-13 at 20:23 +0200, Jeroen Dekkers wrote:
> At Sun, 13 Aug 2006 11:49:06 -0500,
> Hollis Blanchard wrote:
> > 
> > What will happen to the google-soc2006 CVS branch when you're done?
> 
> It should be merged into the mainline.

Well, of course. :) My question wasn't "what _should_ happen?" but
rather "what _will_ happen?".

Who is going to do this? Does this fall outside the scope of your SoC
project? I understand that branches in CVS are extremely cumbersome, so
will this be a difficult process?

-Hollis

Re: Support for reading LVM volumes

[Jeroen Dekkers]

At Sun, 13 Aug 2006 14:51:40 -0500,
Hollis Blanchard wrote:
> 
> On Sun, 2006-08-13 at 20:23 +0200, Jeroen Dekkers wrote:
> > At Sun, 13 Aug 2006 11:49:06 -0500,
> > Hollis Blanchard wrote:
> > > 
> > > What will happen to the google-soc2006 CVS branch when you're done?
> > 
> > It should be merged into the mainline.
> 
> Well, of course. :) My question wasn't "what _should_ happen?" but
> rather "what _will_ happen?".
> 
> Who is going to do this? Does this fall outside the scope of your SoC
> project? I understand that branches in CVS are extremely cumbersome, so
> will this be a difficult process?

You don't have to really merge the branch in CVS. You can just call
diff on both branches and apply the patch on the mainline. Of course
this isn't the most beautiful way, but it works... 

I also think we should switch to a better VCS. I'm actually using bzr
myself. If anyone is interested, I've published my SoC branch and the
CVS on my homepage:
http://dekkers.cx/bzr/grub2
http://dekkers.cx/bzr/grub2-cvs

My preference is bzr, but almost everything is better than cvs. I
would happily use svn, mercurial or darcs for example.

Jeroen Dekkers

Re: moving away from CVS

[Hollis Blanchard]

On Sun, 2006-08-13 at 22:08 +0200, Jeroen Dekkers wrote:
> 
> I also think we should switch to a better VCS. I'm actually using bzr
> myself. If anyone is interested, I've published my SoC branch and the
> CVS on my homepage:
> http://dekkers.cx/bzr/grub2
> http://dekkers.cx/bzr/grub2-cvs
> 
> My preference is bzr, but almost everything is better than cvs. I
> would happily use svn, mercurial or darcs for example.

I agree; I think there are far better replacements for CVS. Personally I
would highly recommend mercurial, but I suppose everybody has their own
preferences. I noticed that Savannah, where the GRUB tree is currently
hosted, offers subversion support...

-Hollis

Re: moving away from CVS

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> On Sun, 2006-08-13 at 22:08 +0200, Jeroen Dekkers wrote:
>> 
>> I also think we should switch to a better VCS. I'm actually using bzr
>> myself. If anyone is interested, I've published my SoC branch and the
>> CVS on my homepage:
>> http://dekkers.cx/bzr/grub2
>> http://dekkers.cx/bzr/grub2-cvs
>> 
>> My preference is bzr, but almost everything is better than cvs. I
>> would happily use svn, mercurial or darcs for example.
>
> I agree; I think there are far better replacements for CVS. Personally I
> would highly recommend mercurial, but I suppose everybody has their own
> preferences. I noticed that Savannah, where the GRUB tree is currently
> hosted, offers subversion support...

I like subversion because it solves most problems, while I do not have
to learn something new.

--
Marco

Re: moving away from CVS

[Johan Rydberg]

Marco Gerards <mgerards@xs4all.nl> writes:

>> I agree; I think there are far better replacements for CVS. Personally I
>> would highly recommend mercurial, but I suppose everybody has their own
>> preferences. I noticed that Savannah, where the GRUB tree is currently
>> hosted, offers subversion support...
>
> I like subversion because it solves most problems, while I do not have
> to learn something new.

Subversion still does not track merges, which I think was the original
reason to why this discussion started.  

Personally I would rather use bzr, but I know our maintainer does not
like it that much (because of the lack of commit hooks.)  But I
wouldn't mind switching to subversion, keep in mind that it will not
be any better than CVS.

~j

Re: moving away from CVS

[Marco Gerards]

Johan Rydberg <jrydberg@night.trouble.net> writes:

> Marco Gerards <mgerards@xs4all.nl> writes:
>
>>> I agree; I think there are far better replacements for CVS. Personally I
>>> would highly recommend mercurial, but I suppose everybody has their own
>>> preferences. I noticed that Savannah, where the GRUB tree is currently
>>> hosted, offers subversion support...
>>
>> I like subversion because it solves most problems, while I do not have
>> to learn something new.
>
> Subversion still does not track merges, which I think was the original
> reason to why this discussion started.  
>
> Personally I would rather use bzr, but I know our maintainer does not
> like it that much (because of the lack of commit hooks.)  But I
> wouldn't mind switching to subversion, keep in mind that it will not
> be any better than CVS.

It is better than CVS, but just not in this specific case.  Anyways, I
do not mind that much about using bzr.  Almost anything is better than
CVS. :-)

--
Marco

Re: Support for reading LVM volumes

[Jeroen Dekkers]

At Sun, 13 Aug 2006 17:13:55 +0200,
Jeroen Dekkers wrote:
> I'm going to work on adding support for LVM to grub-setup now. That's
> the last remaining thing in my SoC project.

This is done now. This means I've finished all the things for my SoC
project. What I've written is a raid module that is able to read RAID
arrays and LVM module that can read LVM volumes, so GRUB is able to
read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has
code that detects that the GRUB root is on a LVM or RAID device and
will embed GRUB after the MBR. It will set the prefix so that the GRUB
kernel can find the rest of the modules and configuration files.

Any comments, bug reports, etc. are welcome. :-)

Jeroen Dekkers

Re: Support for reading LVM volumes

[Marco Gerards]

Jeroen Dekkers <jeroen@vrijschrift.org> writes:

> At Sun, 13 Aug 2006 17:13:55 +0200,
> Jeroen Dekkers wrote:
>> I'm going to work on adding support for LVM to grub-setup now. That's
>> the last remaining thing in my SoC project.
>
> This is done now. This means I've finished all the things for my SoC
> project. What I've written is a raid module that is able to read RAID
> arrays and LVM module that can read LVM volumes, so GRUB is able to
> read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has
> code that detects that the GRUB root is on a LVM or RAID device and
> will embed GRUB after the MBR. It will set the prefix so that the GRUB
> kernel can find the rest of the modules and configuration files.

Congratulations!  Thanks a lot for your contribution. :-)

--
Marco

Re: Support for reading LVM volumes

[Yoshinori K. Okuji]

On Sunday 13 August 2006 21:51, Hollis Blanchard wrote:
> On Sun, 2006-08-13 at 20:23 +0200, Jeroen Dekkers wrote:
> > At Sun, 13 Aug 2006 11:49:06 -0500,
> >
> > Hollis Blanchard wrote:
> > > What will happen to the google-soc2006 CVS branch when you're done?
> >
> > It should be merged into the mainline.
>
> Well, of course. :) My question wasn't "what _should_ happen?" but
> rather "what _will_ happen?".
>
> Who is going to do this? Does this fall outside the scope of your SoC
> project? I understand that branches in CVS are extremely cumbersome, so
> will this be a difficult process?

Anybody can do this. If nobody else wants to do, I will do it...

BTW, it is not difficult to merge branches in CVS, if it is done only once. 
What's difficult in CVS is to track what are merged and what are not merged. 
In this case, the disadvantage does not matter.

Okuji

Re: Support for reading LVM volumes

[Yoshinori K. Okuji]

On Tuesday 15 August 2006 13:30, Jeroen Dekkers wrote:
> > I'm going to work on adding support for LVM to grub-setup now. That's
> > the last remaining thing in my SoC project.
>
> This is done now. This means I've finished all the things for my SoC
> project. What I've written is a raid module that is able to read RAID
> arrays and LVM module that can read LVM volumes, so GRUB is able to
> read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has
> code that detects that the GRUB root is on a LVM or RAID device and
> will embed GRUB after the MBR. It will set the prefix so that the GRUB
> kernel can find the rest of the modules and configuration files.
>
> Any comments, bug reports, etc. are welcome. :-)

You are marvelous! It was very painful for me to filter out applicants for 
SoC, but you got rid of my pain of sin. :)

I think the rest is technical documentation. Could you summerize how it works 
in brief? You can use the wiki or whatever else as you wish.

BTW, are you planning to write an article about your work (e.g. osnews.com, 
free software magazine, etc.)?

Okuji

Re: Support for reading LVM volumes

[Jeroen Dekkers]

At Tue, 15 Aug 2006 14:48:41 +0200,
Yoshinori K. Okuji wrote:
> 
> On Tuesday 15 August 2006 13:30, Jeroen Dekkers wrote:
> > > I'm going to work on adding support for LVM to grub-setup now. That's
> > > the last remaining thing in my SoC project.
> >
> > This is done now. This means I've finished all the things for my SoC
> > project. What I've written is a raid module that is able to read RAID
> > arrays and LVM module that can read LVM volumes, so GRUB is able to
> > read files (GRUB modules, kernels, etc) from RAID/LVM. Grub-setup has
> > code that detects that the GRUB root is on a LVM or RAID device and
> > will embed GRUB after the MBR. It will set the prefix so that the GRUB
> > kernel can find the rest of the modules and configuration files.
> >
> > Any comments, bug reports, etc. are welcome. :-)
> 
> You are marvelous! It was very painful for me to filter out applicants for 
> SoC, but you got rid of my pain of sin. :)

Thanks. :-)
 
> I think the rest is technical documentation. Could you summerize how it works 
> in brief? You can use the wiki or whatever else as you wish.

http://grub.enbug.org/LVMandRAID

I've linked it from the FrontPage. Feel free to ask question or to
modify the page to add things if I forgot anything.

> BTW, are you planning to write an article about your work (e.g. osnews.com, 
> free software magazine, etc.)?

Not really, I'm afraid there isn't really that much exciting to
tell. Maybe I will write down my knowledge about the RAID and LVM disk
structures, because currently the only documentation is the source
code.

Jeroen Dekkers

Re: Support for reading LVM volumes

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

Hello!

On Sun, Aug 13, 2006 at 05:13:55PM +0200, Jeroen Dekkers wrote:
> I've just commited the code for reading LVM volumes.

Congratulations, Jeroen!  :-)

I'll be sure to check (and use!) that sooner or later, but then forever.
Or so.


Regards,
 Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]