MiniLVM vs LVM Inconsistency

I have a confusing phenomenon which doesn't seem crucial but which I 
still would like to resolve.

I have a USB MSD (purchased for holding Zip Backups) which is 
recognized, including the Zip files stored on it.  So, that isn't the 
issue.

MiniLVM showed the Free Space but with no Volume or drive Letter 
assigned, and the JFS volume on it as R.  Since eCS at least used to 
reserve drive R, I changed it to Q.  MiniLVM now shows it as Q.

However, LVM shows the Free Space as Volume [V1] and the drive Letter 
as Q, and the JFS volume as Q->R:.  The Drives Folder is consistent 
with this, and from a command line a Dir command shows Q as Not Ready 
but shows all of the Zip files on R.  (Admittedly, I didn't reboot 
after the MiniLVM operation, but the difference is consistent with the
way it was the last time I explored this problem.)

Any explanation for this inconsistency or way to resolve it?  Also, 
from LVM there seems no way to remove the Volume or drive Letter 
designation for the Free Space.  (In fact, when I highlight the Free 
Space and press Enter the only option is to Create a Volume - 
seemingly inconsistent with the [V1} and Q designations.)


[I investigated the preliminary phase of this problem about probably 6
to 7 weeks ago and got some kind responses.  Unfortunately, I had too 
much to do then and couldn't pursue it; now I'll be D----d if I can 
remember on what forum I posted the issue; must be getting too D--- 
old!  So if the same persons see this posting and wonder why I ignored
the earlier advice, my apologies.]


-- 

I forgot to mention regarding the below that LVM shows the 7 Mb Free 
Space as *->Q: and its type as Compatibility.

DFSee shows the JFS volume on the USB MSD as Drive Rq and displays the
following warning:
EBR16=Rq warning     A Windows-specific extended partition type 0 x0f 
is used.
                                     Some operating systems might not 
see the logical partition.



On Sat, 5 Nov 2005 18:03:36 UTC, "Wayne A. Smith"
<decgroup@thumb.net>
wrote:

> I have a confusing phenomenon which doesn't seem crucial but which I 
> still would like to resolve.
>  
> I have a USB MSD (purchased for holding Zip Backups) which is 
> recognized, including the Zip files stored on it.  So, that isn't the 
> issue.
>  
> MiniLVM showed the Free Space but with no Volume or drive Letter 
> assigned, and the JFS volume on it as R.  Since eCS at least used to 
> reserve drive R, I changed it to Q.  MiniLVM now shows it as Q.
>  
> However, LVM shows the Free Space as Volume [V1] and the drive Letter 
> as Q, and the JFS volume as Q->R:.  The Drives Folder is consistent 
> with this, and from a command line a Dir command shows Q as Not Ready 
> but shows all of the Zip files on R.  (Admittedly, I didn't reboot 
> after the MiniLVM operation, but the difference is consistent with the
> way it was the last time I explored this problem.)
>  
> Any explanation for this inconsistency or way to resolve it?  Also, 
> from LVM there seems no way to remove the Volume or drive Letter 
> designation for the Free Space.  (In fact, when I highlight the Free 
> Space and press Enter the only option is to Create a Volume - 
> seemingly inconsistent with the [V1} and Q designations.)
>  
>  
> [I investigated the preliminary phase of this problem about probably 6
> to 7 weeks ago and got some kind responses.  Unfortunately, I had too 
> much to do then and couldn't pursue it; now I'll be D----d if I can 
> remember on what forum I posted the issue; must be getting too D--- 
> old!  So if the same persons see this posting and wonder why I ignored
> the earlier advice, my apologies.]
>  
>  
> -- 
>  


-- 

On Sat, 5 Nov 2005 18:03:36 UTC, "Wayne A. Smith"
<decgroup@thumb.net> wrote:

> I have a USB MSD (purchased for holding Zip Backups) which is 
> recognized, including the Zip files stored on it.  So, that isn't the 
> issue.
> 
> MiniLVM showed the Free Space but with no Volume or drive Letter 
> assigned, and the JFS volume on it as R.  Since eCS at least used to 
> reserve drive R, I changed it to Q.  MiniLVM now shows it as Q.
> 
> However, LVM shows the Free Space as Volume [V1] and the drive Letter 
> as Q, and the JFS volume as Q->R:.  The Drives Folder is consistent 
> with this, and from a command line a Dir command shows Q as Not Ready 
> but shows all of the Zip files on R.  (Admittedly, I didn't reboot 
> after the MiniLVM operation, but the difference is consistent with the
> way it was the last time I explored this problem.)

At a glance, it sounds like this is a manifestation of a rare logic
problem in MINILVM... or rather, in the DLL I wrote to abstract the
LVM API (LVMLAYER.DLL) which MINILVM uses in turn.

The problem is this: LVMLAYER, quite reasonably, normally tries to 
query the current drive letter from the volume's data structure.  
However, there are some circumstances when this drive letter can be 
reported as NULL, including some occasions when the volume actually 
DOES have a drive letter.  (Most significantly, this happens whenever
you change a volume's assigned letter.  It will then be reported as
NULL until after you close the LVM Engine and re-open it.  I originally
thought this was a bug, but now I suspect it may be intentional.)  When 
this happens, LVMLAYER will query the drive letter from the data 
structure of the (first) underlying partition instead.

The problem is, the partition data structure reports the PREFERRED
(i.e. requested) drive letter, not the ACTUAL drive letter.  It is
occasionally possible for these to be different.

In other words, the drive letter reported by MINILVM may be incorrect
if the volume's 'current' drive letter field reports NULL *and* the
'preferred' drive letter is not the actual one assigned.  

This situation is very rare, which is why it went undetected for so
long.

FWIW, I was made aware of this problem at WarpStock.  I'm not going
to fix it before the final release of the 1.2 media refresh, because
the fix involves some fairly significant (and therefore risky) changes 
to how LVMLAYER and MINILVM work.

I'll try and get it fixed after the refresh is safely out the door,
though.  I expect I'll make use of the BetaZone for testing...


BTW, when you see x:->y: in LVM.EXE, it means that the letter on the 
left is the 'preferred' drive letter, and the one on the right is the 
'current' drive letter.  This notation means that LVM had to reassign 
a letter because of a conflict.

-- 
+---------------------------------------------------------------+
| Alex Taylor                      http://www.cs-club.org/~alex |

On Sat, 5 Nov 2005 19:03:20 UTC, "Wayne A. Smith"
<decgroup@thumb.net> wrote:
Hi Wayne,

> I forgot to mention regarding the below that LVM shows the 7 Mb Free 
> Space as *->Q: and its type as Compatibility.
>  
> DFSee shows the JFS volume on the USB MSD as Drive Rq 

Meaning it has preferred driveletter 'Q' but got R: assigned now.
(LVM would display that as Q: -> R:)

>and displays the  following warning:
> EBR16=Rq warning     A Windows-specific extended partition type 0 x0f 
> is used.
>                                      Some operating systems might not 
> see the logical partition.

That is quite harmeless, all later versions of LVM
can handle that without problems.

However, from you earlier descriptions I have a strong 
suspicion that that first area is NOT freespace, but
rather an unformatted partition ...

I could tell for sure if you would post a QUERY file 
from DFSee that you get with:

	dfsos2 -query

I would expect that to show a partition, not freespace.
If it DOES display freespace, and (mini)LVM does not,
that would be a bug in LVM I would say :-)


Regards, JvW

  
 


--