vhd non contiguous error

why grub4dos reports 2 blocks at the blocklist /whatever.vhd command 

while wincontig or defraggler see just 1 block ?

on hard disk partition, no usb stick

dynamic 10g vhd, only some 5g on disk 

grub4dos 0.4.6a

win10 x64

What you report is EXTREMELY "queer".

Try running the blocklist command in grub4dos and post the result.

Then try running getfileextents:

http://www.msfn.org/...comment=1011369

and/or myfragmenter:
http://www.msfn.org/...comment=1017553

and post results.

The real issue you are facing is probably  that you cannot mount/access the VHD from grub4dos, this is "normal", namely the reason is connected with the "dynamic" nature of the vhd.

I.e. it is likely that what grub4dos "sees" is incorrect because of the (not suitable) image format.

Are you getting an error 60 in grub4dos when mapping?

Or an error 17 when accessing the mounted image?

Though it is written all over the place, I will re-state how grub4dos DOES NOT "understand" the VHD format, it does understand ONLY RAW images and coincidentally a FIXED SIZE VHD image is a RAW image with a single sectors appended to the end of it (which grub4dos ignores).

JFYI, "0.4.6" in itself does not represent a vaild grub4dos verson, you need to state also the date.

Latest grub4dos versions (of the 0.4.6a "branch") do support RAW images (or FIXED VHD's) that are fragmented, though it is anyway advised to have them in a single chunk:

http://reboot.pro/to...ntiguous-files/

Wonko

grub> blocklist /(hd1,1)/14352.vhd

40239152+10908464

map /14352.vhd

error 61 

too many fragments

getfileextents redirects to some advertisement

and www.mydefrag.com seems down but i found it at filehippo

MyFragmenter.exe -i h:\14352.vhd

I am aware that grub4dos can't boot vhd images apart from mapping to them to ram

so it's true i used to get back an error 17

but that changed with this latest grub4dos-0.4.6a-2016-06-03.7z in to this error 61

so i thought something has changed hoping that it might boot it also now.

(btw dymanic vhd is booting just fine through --mem,  only the loading to ram progress is not shown at all)

The non-contiguous file error should be 60, if you don't have that, the file is contiguous (as the blocklist command output shows), the first number is the beginning of the file, the one after the + is the number of sectors in the file.

grub4dos:

40239152 <- offset (in sectors) of the extent -> 40239152*512=20602445824 <- offset (relative to volume)

10908464*512=5585133568 <- size of the single extent

Myfragmenter (assuming a "normal" 4096 bytes cluster):

5029894*4096=20602445824

1363558*4096=5585133568

It is possible that the error 61 is caused by *something* else.

As a side note, usually there is no reason to use a "dynamic" VHD file in a booting environment, what is the actual reason why you are using that?

I mean, you have to choose:

a. the images is 10 Gb, it's actual contents need only 5 Gb and it is NOT subject to increase noticeably  in size -> use a 5 Gb static image

b. the image is 10 Gb, its actual contents need only 5 Gb and it is subject to a limited increase in size (let's say 20%) -> use a 6 Gb static image

c. the image is 10 Gb, its actual contents eed only 5 Gb and it is subject to increase in size up to 10 Gb -> use a 10 Gb static image

Mapping to mem a dynamic image will anyway be slower than direct mapping a much bigger static image (besides the need of large amounts of RAM).

Wonko

So it reports a "too many fragments" error 61 while itself finds 1 block.

I also checked on a fixed vhd and it seems as it's going to boot but now windows come up with a "inaccessible boot device".

Anyhow, i was just hoping, nothing else, i wanted to avoid having to deal with all this bcdboot/bcdedit terror every time.

What happens is that Win10 supports Lzx compression which gives us the opportunity to have tiny windows installations

and Grub4dos loads say an 1.87g vhd to ram in about 6 seconds.

Dynamic is preferred cause of the creation of temp files during the normal operation of a windows system

and i didn't notice any difference in loading times from a fixed one, is all about very small vhds anyway. 

Thank you for the replies, they were revealing.

Edited by Camiel, 10 June 2016 - 05:42 PM.

Dynamic is preferred cause of the creation of temp files during the normal operation of a windows system

and i didn't notice any difference in loading times from a fixed one, is all about very small vhds anyway. 

Well, you will have to explain that (the reasoning) to me .

Dynamic VHD's (AFAIK) can only grow in size, so - before or later - they will grow up to the "max actually needed" or "allowed"...

Mind you, de gustibus not disputandum est :

https://en.wikipedia...est_disputandum

but really I am failing to see the advantage, it would make (to me) much more sense to have a ramdisk to hold the temp files and thus need a smaller fixed vhd, or actually having a very small "OS image" and have all the non boot critical parts mounted to the flesystem from another image.

Wonko

It's true, before i realize that g4d could load dynamic vhds

i was actually using Imdisk to mount a ram drive at startup and using that as temp.

It's more or less the same thing, i'm still experimenting.