Re: [Qemu-devel] Re: replies

[Damien Mascord <tusker@tusker.org>]

Hi guys,

Excuse my ignorance, but would there be an fdisk library that you could 
just call the functions, or even duplicate the functionality that you 
need from fdisk into a binary of your own ?  Because it is possible that 
a new version of fdisk will change it's screen output and "wreck" lomount...

Damien

Jim C. Brown wrote:
> On Sun, Jun 27, 2004 at 02:12:07PM +0700, Mulyadi Santosa wrote:
> 
>>Hello Jim :-)
>>
>>
>>>BTW why do you check for total sectors? This isn't needed (so removing it
>>>doesnt break anything) and it breaks on my fdisk v2.10s (also you scan for
>>>one extra line). Can I see the output of fdisk -lu and what your
>>>fdisk version is? Odds are good that lomount will need to know the fdisk
>>>version to correctly parse the output.
>>
>>:-) Oh geez, maybe I forgot to by "bypass" total sector :-)
>>BTW, here is output of fdisk -lu /mnt/qemu/myimage (my fdisk version is v2.11y 
>>on RH 9 GPL edition):
>>[[Start of Output]]
>>You must set cylinders.
>>You can do this from the extra functions menu.
>>
>>Disk /mnt/qemu/myimage: 0 MB, 0 bytes
>>16 heads, 63 sectors/track, 0 cylinders, total 0 sectors
> 
> 
> I get this:
> 
> Disk mnx2.img: 0 heads, 0 sectors, 0 cylinders
> 
> I am curious ... how does your fdisk know what the heads and sectors/track are?
> 
> 
>>Units = sectors of 1 * 512 = 512 bytes
> 
> 
> For this line, mine only shows:
> 
> Units = sectors of 1 * 512 bytes
> 
> Your fdisk is better ... it does the math for us ;)
> 
> 
>>            Device Boot    Start       End    Blocks   Id  System
>>/mnt/qemu/myimage1   *        63   1016063    508000+  83  Linux
>>/mnt/qemu/myimage2       1016064   1228751    106344   82  Linux swap
> 
> 
>>Partition 2 has different physical/logical endings:
>>     phys=(1023, 15, 63) logical=(1218, 15, 63)
>>[[end of output]]
> 
> 
> That I don't get ... but thats probably because my fdisk has no clue what the
> geometry is (when I tell it, I get a ton of those errors).
> 
> 
>>Maybe it is caused by version difference in fdisk, what do you think?
> 
> 
> Clearly so. Now we just need to figure out what to do about it... having
> lomount support several different fdisk output formats is possible, but tricky.
> 
> 
>>NB: Jim, maybe we can do "tag team" again on disk resizing......how do you 
>>think? I will write resizer once I have spare time ASAP...but first I will 
>>follow your tips for resizing raw disk image
> 
> 
> It took me a bit of experimentation to figure out how to do all of that. I too
> was unable to find any information on this topic while searching (the closest
> I can was the tool that comes with DOSMinix to resize DOSMinix images ...
> DOSMinix uses raw disk images as well, so that's where I got the idea from).
> 
> Writing a disk resizer wouldn't be terribly difficult. All it needs to do
> is add zeros to grow the disk image, or truncate it when we are shrinking.
> The hard part is getting the geometry right. I wouldn't know how to do this
> myself. (You would have to make sure that the new geometry doesn't end up
> messing up the ordering of the sectors, and you also need to write out the
> new geometry somewhere on the disk image).
> 
> [Be careful tho ... resizing raw disk images can be very tricky (if you're
> growing its not such a big deal (who cares abou a few unusable kb at the end of
> the disk) but when you are shrinking you have to be very careful). Of course,
> its easier than merging 2 disk images together (I still haven't figured out
> how that's done).]
> 
> 
>>regards
>>
>>Mulyadi
> 
> 


-- 
Damien Mascord (tusker at tusker dot org)
GPG key 2CB181BE / 93B2 EF21 0C7C F022 F467  7966 219E 92B3 2CB1 81BE