qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: replies


From: Jim C. Brown
Subject: [Qemu-devel] Re: replies
Date: Sun, 27 Jun 2004 14:26:13 -0400
User-agent: Mutt/1.4i

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

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]