Gecko/20101207 Thunderbird/3.1.7   
   UTC)   
   .linux.setup:7797 comp.os.os2.setup.storage:381   
   From: Jonathan de Boyne Pollard    
      
    I guess my real point was that this problem isn't specific to LVM,    
   > although it's possibly specific to OS/2 in general.   
   >   
   Well this particular problem *is* specific to LVM.   
      
   >> It's what IBM's LVM is doing that isn't fine. It's making unwarranted    
   >> assumptions about where it can just grab an unallocated disc block    
   >> without explicitly allocating it. As I noted, other disc management    
   >> systems *do not do things this way*. Microsoft's Logical Disk Manager    
   >> uses a special partition, whose type is "LDM Metadata" (EFI partition    
   >> type 5808c8aa-7e8f-42e0-85d2-e1e90434cfb3), and puts the metadata    
   >> there. The Linux LVM (we are told) stores the metadata within each    
   >> partition. There's a reason that the rest of the world doesn't do    
   >> things the IBM LVM way, and hasn't done for at least a decade now    
   >> (There is Windows 2000 Server doco that talks about the pitfalls of    
   >> expecting unallocated areas of the partition table to be usable.),    
   >> and this experience *is* that reason. It's a flawed and selfish    
   >> design and doesn't work.   
   >>   
   > Begs the question of course... what, if anything, can be done about it?   
   >   
   > I suppose some ambitious developer could rewrite LVM, although when    
   > IBM open-sourced it for the Linux people to use, they only seem to    
   > have released half of it: LVM.DLL was open-sourced, but not (AFAIK)    
   > OS2DASD.DMD and OS2LVM.DMD, which AIUI do fairly critical parts of the    
   > work...   
   >   
      
   They do for OS/2.  But they aren't necessary for another operating    
   system, since the device driver model of, say, Linux is quite different    
   to that of OS/2.  What one needs in such circumstances are good and    
   thorough specifications for the on-disc data structures, which I presume    
   that there were.  From that one can write a driver.   
      
   It's worth noting, too, that drivers may are not strictly necessary for    
   other operating systems that already have LVM mechanisms.  The Linux LVM    
   model, we are told by the not-very-reliable-when-it-comes-to-computers    
   Wikipedia, is for the kernel to only know how to stitch multiple    
   discontiguous disc slices together to make a single volume, that a    
   filesystem driver then sits on top of.  All of the working out exactly    
   *what* slices to stitch together is the province of applications, not    
   the kernel.  Follow through on that model, and support for IBM LVM    
   becomes a simple case of parsing the on-disc LVM metadata that describes    
   where the disc slices are, and issuing the relevant system calls to tell    
   the Linux kernel what to stitch to what.  Of course it's not *quite*    
   that simple for Linux in reality, but the principle is a general one.   
      
   For IBM OS/2, yes one does need replacement DMDs, because it's the DMDs    
   that go looking at partition tables and decide what disc slices are what    
   on a disc.   
      
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)