LVM partition table extensions
Jonathan de Boyne Pollard
MBR partitioning scheme) from the IBM Boot Manager MBR partition table
extensions. Thanks to information provided by Alex Taylor, I've now
updated it so that it uses the IBM LVM metadata, falling back to the IBM
Boot Manager partition table extensions if the IBM LVM metadata aren't
there. I've also updated DASDPART so that it does the same thing.
My test systems here don't have IBM's LVM. The EFI partitioning scheme
is the way of the future, and my test systems have EFI partition tables
and MBR partition tables with no more than the original IBM Boot Manager
extensions. But Dave Yeo, whom I believe has OS/2 systems with IBM's
LVM, was going to have a go with my Boot Manager. I'm still waiting to
hear back from him. (You'll of course now need the new Boot Manager
that I've just made, M. Yeo.) I've added in the IBM LVM partition table
support blind, and, in the absence of documentation as to the exact
algorithm for locating the IBM LVM metadata (a point that we've
discussed before, with reference to how something in Ubuntu tidies up
container partitions in MBR partition tables to eliminate otherwise
unusuable "holes" that waste space) this might require some tweaking to
cover all possibilities, which of course I cannot do here without
something to test against. If you want to beat M. Yeo to the finishing
post, drop me a line. (-:
I say that the EFI partitioning scheme is the way of the future. In
fact, it's the way of the present, if one takes off the OS/2-tinted
glasses. The rest of the world is already going EFI, and has been for
some several years now. (My Boot Manager and DASDPART tool already
understand EFI partition tables.) So don't expect wonders in the way of
OS/2 LVM partition table support. I'm going to work a little more on
incorporating the IBM LVM drive letter information into things like my
Boot Manager. But if you want an OS/2 LVM tool that will do all of the
volume and partition management, M. Taylor is still the person to bribe,
not me. (-:
Roderick Klein
I try to keep track of the latest developments on hardware/software for
OS/2. It kind of my job to see what things get priority in what needs to
be worked on for eComStation.
As the opinions regarding what is priority for eComStatiom vary, its
kind of interesting to make you pick what to work on next.
My take on the EFI stuff is that I was also certain for some time that
EFI was going to be they standard to come. Thats certainly how Mac OS
works. In server environments EFI (GPT disc layout) is certainly the way
to go. I have so far not ran into systems with a GPT disc layout.
I have one source of information that is in general pretty good and
following mayor trends in the ICT sector. Its the German computer
magazine Computer Technik. What I have been able to see from that
is that it rather seems the MBR will not go away right now but
rather will remain the main mode of disc usage.
I understood from an article they (hard disc industry/software) would
move from 512 bytes sectors to 4 KB sectors. That would give discs upto
16 TB.
What do you mean BTW with "My bootmanager".
I'm interested to look at EFI for eCS. But I can not put my eggs in all
baskets for eComStation.
Roderick Klein
Mensys
madodel
Any chance you will be at Warpstock, either in Haarlem next week or in the
US in a few months? I'd love to see a presentation on this. Between this
and your disk utilities you are doing some much needed updates for OS/2 and
eCS.
Mark
--
Posted from my iPad
Jonathan de Boyne Pollard
> EFI was going to be they standard to come. Thats certainly how Mac OS
> works. In server environments EFI (GPT disc layout) is certainly the
> way to go. I have so far not ran into systems with a GPT disc layout.
>
There, that has been around for several years at this point, written by
people who do things like triple-boot Linux, MacOS, and Windows NT.
This MacTech article, for example, dates from 2006:
http://mactech.com./articles/mactech/Vol.22/22.11/TripleBoot/index.html
Things have come along a way in the years since. There are now, for
example, a lot more utilities that enable hybrid MBR/EFI partitioning or
non-destructive conversion from MBR partitioning to EFI partitioning.
DASDPART, mentioned in my preceding post, is indeed one of them.
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/converting-mbr-to-efi-partitioning.html
The world actually *already is* going EFI, and has been for some years.
And now that hard discs in the home computer market are within a stone's
throw of the hard upper limit on the MBR partitioning scheme, that's
going to speed up some. Moreover, I've been telling the world for some
time that there's a 2TiB limit on the
load-and-run-the-Volume-Boot-Record mechanism, caused not by the
partitioning scheme but by a 32-bit BPB field. People are going to
start hitting that pretty soon, too. Overcoming it involves an
operating system bootstrap mechanism that doesn't need to use the BIOS
Parameter Block to locate the boot volume, which in turn means an EFI
operating system boot loader or something like it. So not only is there
growing pressure to switch to the EFI partition table scheme, but
there's growing pressure to switch to the EFI bootstrap mechanism, too.
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/bios-parameter-block.html#V3.4
The only things that are mitigating the latter pressure are things like
Windows 7's "System Reserved" partition. Expect "You must have a System
Reserved partition and it must reside below the 2TiB line." to become a
Frequently Given Answer within the next few years. And expect a lot of
confusion from the "I used the EFI partition scheme, but I still seem to
have a 2TiB problem." folk. The BPB limit isn't as widely known as the
MBR partition scheme limit, and changing the partition scheme is only
half the solution.
Jonathan de Boyne Pollard
>
keep asking what they mean, since their meaning is so straightforward,
but here's the explanation posted to comp.os.os2.setup.misc in April
2010 once again:
> It's no secret. It refers to ... erm ... my ... erm ... boot
> manager. I wrote one. It's mine. It's my boot manager.
Jonathan de Boyne Pollard
> the US in a few months?
>
> I'd love to see a presentation on this.
>
I don't have presentations, but I have the odd blurb. I sent a
hyperlink to you a little while ago that listed a blurb for CHKVOL. In
the same directory as that blurb, you'll find a slightly out of date
blurb for my Boot Manager (which I need to update with recent
developments). I don't have a blurb for DASDPART, but in the same
directory as the CHKVOL command reference, you'll find a command
reference for DASDPART. A one-sentence, not-quite-accurate, summary is
that DASDPART is intended to fill the same niche as Microsoft's DISKPART
does on Windows NT.