Jump to content











Photo
- - - - -

Reducing wimboot source wim file using LZX Compression, and VHD using gzip or LZ4 Compression, to save room, and also load faster on RAM

wimboot ramboot lzx gzip lz4 vhd

Best Answer alacran , 26 March 2019 - 10:05 PM

We could say that this thread is a continuation of: Making the smallest Win10 install (Wimboot mode) on 512 MB VHD

 

It was necessary to run some additional test using the info from cdob post No. 95: http://reboot.pro/to...e-4#entry210231

 

 

lz4.exe -12  --content-size --favor-decSpeed e:\win.vhd e:\win.vhd.lz4

 

LZ4 compression is better and faster than using GZ, or any other option, it gave me the faster loading to Ram times, also noticed that when loading from an slow device (as my MicroSD) it has the best efect.

 

All test ran on same I3 3225, 3.3 GHZ, 8 GB Ram at 1333 MHZ, Rambooting from SSD Adata SU650 into Adata XPG enclosure 3.0 USB.

 

This are my findings:

 

Speed:

VHD								Time to load on RAM

1 - 10x64-WB.vhd Ramboot using g4d  grub4dos-0.4.6a-2018-12-23		12 seconds

2 - 10x64-WB.vhd.gz Ramboot using g4d  grub4dos-0.4.6a-2018-12-23	7 seconds

3 - 10x64-WB-EXP.vhd Ramboot using g4d  0.4.5c Modd by kyrionix		4 seconds

4 - 10x64-WB.vhd.lz4 Ramboot using g4d  grub4dos-0.4.6a-2019-03-25	3.67 seconds

Saved espace:

VHD				Used	Saved espace

10x64-WB.vhd			1536 MB	0 % saved espace

10x64-WB.vhd Expandable		480 MB	68.75 % saved espace

10x64-WB.vhd.gz			233 MB	84.83 % saved espace

10x64-WB.vhd.lz4		135 MB	91.21 % saved espace

It is very possible I am getting close of maximum loading speed possible for this PC and this is influencing results.

 

On a single test I ran from my MicroSD, the 10x64-WB.vhd.lz4 loaded to Ram on 14.68 seconds wich is really a very good time for that device, and it was plugged to USB 2.0

 

Conclusions:

 

If Rambooting from a fast device as an SSD use expandable VHDs, they have very good speed and a resonable saved espace, do no require any additional compression, they are capable to Ramboot and also can be booted from Windows bootmanager, so it is not a big issue if they can't boot as Filedisk using grub4dos.

 

If Rambooting from a not so fast device as an SSD, we have the alternative to use LZ4 compressed VHDs, wich are the faster option and also save more espace than any other option, but they are only usefull for Rambooting, we can not boot them as Filedik using grub4dos or from Windows Bootmanager, this limitations also apply to GZ compression.

 

Thanks to all members of the forum who collaborated with this thread with info and suggestions, for the realization of all this tests:

 

antonino61, Wonko the sane, karyonix, tinybit, cdob and yaya for fast fixing grub4dos-0.4.6a-2019-03-25

 

 

Just to make a summary of all we have learned/tested/proved/improve on this thread:

From previous Post: http://reboot.pro/to...e-4#entry210209

 

LZX compressed wim files for Wimboot VHDs do not fail anymore during boot or Ramboot. See: http://reboot.pro/to...am/#entry210021

 

With this hight compression I have found If we don't add those items on [PrepopulateList], especially the first two we will have troubles during Ramboot

 

Saving 20 % espace using LZX compressed wim files. See: http://reboot.pro/to...am/#entry210021

 

Only things we have to do in a different way to reduce about 20 % the size of our source win file is: ..........

 

Tested GZ compresed VHDs and found they load faster on Ram (almost about 1/2 time).See: http://reboot.pro/to...am/#entry210031

 

I compressed 10x64-WB.vhd with 7-zip GZ Ultra as 10x64-WB.vhd.gz , it took 15 min, but file is now 233 MB

 

Saving about 85 % espace if using GZ compresed VHDs, See. http://reboot.pro/to...am/#entry210031

 

....but file is now 233 MB so it reduced a lot the size 84.83 %,......

 

Improved speed using GZ compression on VHDs See: http://reboot.pro/to...am/#entry210031

 

So there is a big improvement in time to load in Ram (43.75 % less time)

 

Testing expandable VHDs Ramboot capability, and found it was failing.See: http://reboot.pro/to...e-2#entry210068

 

It fail to load on Ram, still verifiying to try to find if I made a mistake before say it do not work,

 

Detect the last grub4dos 0.46a version capable to Ramboot expandable VHDs. See: http://reboot.pro/to...e-2#entry210089

 

grub4dos-0.4.6a-2017-12-20 is last version capable of Ramboot dynamic VHDs, the next version grub4dos-0.4.6a-2017-12-23 Fails.

 

Thanks to karionix who detected where was exactly the two lines disabled on grub4dos 0.46a after 2017-12-20, See: http://reboot.pro/to...e-2#entry210101

 

The codes to read hard disk footer in line 185 and read dynamic disk header in line 209 were just "disabled".

 

Improved again time to load on Ram , using Expandable VHDs. See: http://reboot.pro/to...e-2#entry210074

	VHD							Time to load on ram

1 - 10x64-WB.vhd Ramboot using g4d  v0.46a Dic 2018            		12 seconds

2 - 10x64-WB.vhd.gz Ramboot using g4d  v0.46a Dic 2018            	7 seconds

3 - 10x64-WB-EXP.vhd Ramboot using g4d  0.4.5c Modd by kyrionix		4 seconds

Saved espace using expandable VHDs compared to 1.5 GB fixed size VHDs. See http://reboot.pro/to...e-3#entry210115

VHD			Used	Saved espace

10x64-WB.vhd		480 MB	68.75 % saved espace

10x86-WB.vhd		360 MB	76.56 % saved espace

8x64-WB.vhd		416 MB	72.91 % saved espace

W864ESP1-WB.vhd		364 MB	76.30 % saved espace

Got the attention of tinybit and yaya (grub4dos development team) and thanks to it, get in about 2 days a new fixed release. See: http://reboot.pro/to...e-3#entry210171

 

yaya fixed it.

 

And this new posts related to LZ4 Compression:

 

karyonix info about LZ4, See: http://reboot.pro/to...e-4#entry210229

cdob info and commands for LZ4, See: http://reboot.pro/to...e-4#entry210231
 

Analyzing why the difference of speeds: http://reboot.pro/to...e-5#entry210265

 

Comparing the 2 options suggested by cdob for LZ4 Compression: http://reboot.pro/to...e-5#entry210278

 

When having x86 and x64 versions you can make a wimboot source wim file with multiple indexes to save espace, see: http://reboot.pro/to...am/#entry210406

 

And for all lazy people wimb just made a program to make almost all this, things not available on his program are compressions of VHDs and multi-index wimboot source wim files:

 

VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD by wimb: http://reboot.pro/to...-for-os-in-vhd/

 

And finally now, there is also available this lz4_compressor GUI: http://reboot.pro/to...lz4-compressor/

 

I only hope this thread has helped some of us to learn something.

 

alacran

Go to the full post


  • Please log in to reply
165 replies to this topic

#51 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 March 2019 - 07:52 PM

 
 
See the diff of stage2/dec_vhd.c in 2017-12-23.
https://github.com/c...2dc585d418454e3
The codes to read hard disk footer in line 185 and read dynamic disk header in line 209 were just "disabled".

Yep, thanks :), but:

1) WHY (the heck)?

2) WHY (the double heck) it was not written in the log, I mean it seems to me like a non-trifling change (that probably makes it so that every later release won't work)

 

:duff:

Wonko



#52 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 23 March 2019 - 08:06 PM

@ karyonix

 

You have found the source of the problem, thanks my friend.

 

 
 
See the diff of stage2/dec_vhd.c in 2017-12-23.
https://github.com/c...2dc585d418454e3
The codes to read hard disk footer in line 185 and read dynamic disk header in line 209 were just "disabled".

 

Yes, now with your info it seems to me it was done by some one (provably to test something else), and latter he/she just forgot to enable them again.

 

Now, what we can do to get this fixed from 0.46a developers?

 

In the main time, could you make the change on grub4dos-0.4.6a-2018-12-23 as a temporary resource?

 

alacran



#53 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 March 2019 - 03:20 AM

We already know the expandable VHDs load faster on Ram.

 

Now I want to annalise the saved espace, when using this approach.

 

I have made several 1.5 GB dynamic expandable VHDs to see how much saved espace we can get using this approach comparing with 1.5 GB fixed size VHDs:

VHD			Used	Saved espace

10x64-WB.vhd		480 MB	68.75 % saved espace

10x86-WB.vhd		360 MB	76.56 % saved espace

8x64-WB.vhd		416 MB	72.91 % saved espace

W864ESP1-WB.vhd		364 MB	76.30 % saved espace

This 4 VHDs occupy on your USB device only 1620 MB = 1.582 GB
If they were 1.5 GB fixed size each, they occupy 6GB, so this represents saving 4.418 GB

 

Of course each time we boot one of them as Filedisk it occupy the full 1.5 GB, so we need some extra 1200 MB in the worst escenario (10x86-WB.vhd), to remain always free on our USB device to allow the expansion.

 

alacran



#54 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 24 March 2019 - 07:40 AM

how about karyonix lz4? Me, I have reduced dynamic vhd size to 260mb, it preloads ok, but as for booting, no dice yet --> wrong table or something it yields.



#55 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 24 March 2019 - 12:32 PM

Another one of my things said in passing (obiter dictum): supposing a new version of one of your favorite apps or programs comes out: u wanna try it out and this happens to be one you have to install. U do and realize that your used space on this new dynamic vhd has grown and by logic ur free space has shrunk. will u make a new wim and wimboot again or will u stay as you are with the new software out of the wim, presumably until the red color on ur vhd used space appears (might as well be after 2-3 further additions)? 

nino



#56 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 March 2019 - 02:26 PM

Of course each time we boot one of them it occupy the full 1.5 GB, so we need some extra 1200 MB in the worst escenario (10x86-WB.vhd), to remain always free on our USB device to allow the expansion.

I lost you here :w00t:

.

IF the dynamic VHD's are for RAM booting only, they expand in memory, not on disk.

 

:duff:

Wonko



#57 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 March 2019 - 03:49 PM

I lost you here :w00t:

.

IF the dynamic VHD's are for RAM booting only, they expand in memory, not on disk.

 

:duff:

Wonko

 

Yes, but I was thinking when they are Filedisk booted, I just edit previous Post to make this more clear.

 

You are totally right but it applies only for Ramboot, remember they can also be Filedisk booted by Windows manager or grub4dos if you want, perhaps to make some permanent change you need as install a program or copy some portable to Documents, etc.

 

alacran



#58 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 24 March 2019 - 04:04 PM

Dear Wonko, and this time alacran as well, u lost me entirely this time. I meant not the normal expansion, but the installing of software which I do not think will go straight to the wim, but stop at vhd level, or am I wrong?

#59 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 March 2019 - 04:09 PM

@alacran
I don't know if it is actually possible to "filedisk" boot dynamic .vhd's, at least karyonix (that should know a thing or two on the matter ;)) excluded it when he presented the grub4dos patch:
http://reboot.pro/to...mic-vhd-to-ram/
 
 

I added dynamic VHD reading capability to this modified grub4dos.
You can use with map --mem.
It will reads content of disk image in dynamic VHD.
Don't map dynamic VHD directly without --mem.

Differencing VHD is not supported.

Maybe this has later changed? :unsure:

Or you mean using the same .vhd (dynamic) with svbus or firadisk (via grub4dos) as RAMdisk/--mem boot and then use it with the "native" booting methods? :dubbio:
 
:duff:
Wonko

#60 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 24 March 2019 - 04:33 PM

Either native or not, try installing anything on vhd+wim and see if you do not have used space on vhd that is permanently augmented.

#61 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 March 2019 - 04:33 PM

Another one of my things said in passing (obiter dictum): supposing a new version of one of your favorite apps or programs comes out: u wanna try it out and this happens to be one you have to install. U do and realize that your used space on this new dynamic vhd has grown and by logic ur free space has shrunk. will u make a new wim and wimboot again or will u stay as you are with the new software out of the wim, presumably until the red color on ur vhd used space appears (might as well be after 2-3 further additions)? 

nino

 

To only test a program you can install it on Ramboot and see if you like it or not, then if you decide you want to keep it you can install it booting as Filedisk, and after that as long as you have enought free espace that's all, when you are short of room, it is time to make a rebuild.

 

Remember I suggested 1.5 GB VHDs for PCs with a minimum of 4 GB of Ram, also on previous post I demostrate a dynamic expandable VHD of 1.5 Max. and another of 4 GB Max., both are loaded to Ram on exactly same time 4 seconds.

 

See:

Booting 10x64-WB-EXP.vhd 4 GB expandable VHD: http://reboot.pro/to...e-2#entry210073

Booting 10x64-WB-EXP.vhd 1.5 GB expandable VHD: http://reboot.pro/to...e-2#entry210074

 

So after you paid a big sum of money for 64 GB of Ram:

 

1 - I don't see why make your VHD very small since an expandable VHD of virtually any size is only the size of the info contained into it.

 

2 - Then loading on Ram and full booting fime should be the same.

 

3 - Having such amount of Ram unused is just a waste of money.

 

If I would want to always Ramboot (and exceptionally Fdisk boot) I would make an expandable wimboot VHD of 4 GB for PCs with 8 GB Ram (as mine). 

 

Just try this as a guide if you have more than 4 GB of Ram the size of your expandable VHD may be 1/2 of your installed Ram.

 

This DO NOT apply to PCs with a minimum of 4 GB of Ram, for this case I recommend a VHD of maximum 1.5 GB.

 

alacran



#62 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 March 2019 - 04:51 PM

@alacran
I don't know if it is actually possible to "filedisk" boot dynamic .vhd's, at least karyonix (that should know a thing or two on the matter ;)) excluded it when he presented the grub4dos patch:
http://reboot.pro/to...mic-vhd-to-ram/
 
 
Maybe this has later changed? :unsure:

Or you mean using the same .vhd (dynamic) with svbus or firadisk (via grub4dos) as RAMdisk/--mem boot and then use it with the "native" booting methods? :dubbio:
 
:duff:
Wonko

 

I'm using grub4dos-0.4.6a-2017-12-20, and it do not have those limitations, it works as any other version of 0.46a but still having dynamic VHDs load to Ram capavilities (lost on next version), so even if I haven't try it to Filedik boot my VHDs (and I will not try it because booting this way any change will be permanent and used size on VHD will increase) I assume it is possible, if not you can still bot this way using Windows bootmanager.

 

From my post when testing grub4dos-0.4.6a-2016-12-12: http://reboot.pro/to...e-2#entry210086

 

 

This is the fastest option for Ramboot, I didn't test Filedisk but it should work too, but even in the remote case it fails Windows bootmanager can boot without a problem any Dynamic (expandable) disk.

 

EDIT: From: http://reboot.pro/to...am/#entry210159

 

After finally testing Filedisk booting from an expandable VHD using grub4dos I can confirm, no matter the version (upto today) it will not boot.

 

alacran



#63 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 March 2019 - 05:20 PM

I'm using grub4dos-0.4.6a-2017-12-20, and it do not have those limitations, it works as any other version of 0.46a but still having dynamic VHDs load to Ram capavilities (lost on next version), so even if I haven't try it to Filedik boot my VHDs (and I will not try it because booting this way any change will be permanent and used size on VHD will increase) I assume it is possible, if not you can still bot this way using Windows bootmanager.

 

Look, it's pretty much binary, EITHER you try to Filedisk booting AND report success[1] OR it didn't happen and it is ONLY wishful thinking on your part.

 

The programmer that implemented the feature explicitly stated to NOT Filedisk map a  dynamic .vhd, so you CANNOT assume that is possible and MUCH MORE THAN THAT you cannot report "recommendations" on how to prevent something that might derive from something else that cannot be done and it is just something you assume.

 

An assumpion on another assumption AND reported as a fact. :frusty:

 

BTW, it is also incorrect that booting a dynamic VHD as Filedisk (IF possible at all) will make it expand to full size, the size on disk is increased proportionally to the (hypothetical) increase in the contents of the .vhd (that not necessarily are increased by booting from it).

 

:duff:

Wonko

 

[1] AND detail how EXACTLY you booted the dynamic disk as Filedisk



#64 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 March 2019 - 05:45 PM

After finally testing Filedisk booting from an expandable VHD using grub4dos I can confirm, no matter the version (upto today) it will not boot.

 

But this is not the only way to but it NOT as Ramdisk as I already said we may use Windows bootmanager to boot this expandable VHDs, Windows has this capavility, and when I said:

 

 

Of course each time we boot one of them as Filedisk it occupy the full 1.5 GB, so we need some extra 1200 MB in the worst escenario (10x86-WB.vhd), to remain always free on our USB device to allow the expansion.

 

It means you need to have this free espace available to boot your VHD, just by attaching this VHD to your actual running system it is shown on Disk Manager as ocupping/having 1.5 GB size.

 

On the other hand when I said:

 

 

I haven't try it to Filedik boot my VHDs (and I will not try it because booting this way any change will be permanent and used size on VHD will increase)

 

This is related to all those drivers installed, logs, and temporary files created during this boot, they will remain on the VHD, altering the initial size of the pristine file.

 

Edit: I will make some notes on previous post related to this subject, to avoid confusion on future readers.

 

alacran


  • antonino61 likes this

#65 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 March 2019 - 06:26 PM

It means you need to have this free espace available to boot your VHD, just by attaching this VHD to your actual running system it is shown on Disk Manager as ocupping/having 1.5 GB size.

 

Hmmm.

 

It seems to me like you have a "wrong" method to check file size.

 

Open Explorer.

 

Right click on the not-yet (and never before) mounted .vhd file.

 

Jolt down:

1) File Size
2) File Size on disk

 

Mount the .vhd to a drive letter.

Unmount the .vhd.

 

 

Right click on the just unmounted .vhd file.

 

Jolt down:

1) File Size
2) File Size on disk

 

What differences do you see?

 

Then repeat (on the not mounted VHD) after having "Filedisk" booted from it (clearly NOT using grub4dos, but another method AND describe the method used).

 

What differences do you see now?

 

:duff:

Wonko



#66 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 March 2019 - 09:23 PM

Of course no VHD disk changes its size just by mounting and unmounting it.

 

But when booted it needs the free size contained into the expandable VHD, if not Windows can't work as it is always writing something, you can not boot Windows on a non writable disk, that's a known fact. We are talking here of full Windows not WinPEs.

 

When it is booted on Ram, there is the free required espace to write, the free espace on the VHD is located on Ram.

 

When it is booted from a physical Mass Storage device, there is the espace required to write, the free espace on the VHD is located on Mass Storage device now.

 

And just by booting it using Windows bootmanager it does change its size as said.

 

See attached picture, left is before booting it ever with Win bootmanager (only Rambooting), Right is after booting it with Win bootmanager (without doing anything, just booting and it was turned off).

 

alacran

Attached Files


  • antonino61 likes this

#67 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 24 March 2019 - 10:38 PM

u see, wonko, alacran is trying to tell u a fraction of what i had told u already. Mind u, it is alacran, not me, so u can understand.

as far as alacran is concerned, there is no advantage in having huge vhds, no matter how much ram, the best is to adjust it to the first stable version expansion-wise, which is around 1.5gb or 2gb. that way the used space of the vhd will not grow. the excess ram u see in my case, as I already told wonko, better use it for caching disks. believe me, I have write speeds higher than read speeds. U c, the slowest thing here is booting.

nino



#68 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 24 March 2019 - 10:47 PM

Another thing i told u guys a couple of weeks ago. Is it possible that disk numbering between bios and gru4dos is inconsistent or has different levels of consistency between cold boots and reboots? when I told u that I had vhds loading into ram ok at reboot but hardly ever at cold boot, u ascribed this to bad ram. does that imply that cold ram (at cold boot) is more likely to be faulty than hot ram (at reboot)?

nino



#69 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 25 March 2019 - 12:05 AM

as far as alacran is concerned, there is no advantage in having huge vhds, no matter how much ram, the best is to adjust it to the first stable version expansion-wise, which is around 1.5gb or 2gb.

 

NO, I said exactly oposite, see: http://reboot.pro/to...e-3#entry210156

 

 

Remember I suggested 1.5 GB VHDs for PCs with a minimum of 4 GB of Ram, also on previous post I demostrate a dynamic expandable VHD of 1.5 Max. and another of 4 GB Max., both are loaded to Ram on exactly same time 4 seconds.

 

See:

Booting 10x64-WB-EXP.vhd 4 GB expandable VHD: http://reboot.pro/to...e-2#entry210073

Booting 10x64-WB-EXP.vhd 1.5 GB expandable VHD: http://reboot.pro/to...e-2#entry210074

 

So after you paid a big sum of money for 64 GB of Ram:

 

1 - I don't see why make your VHD very small since an expandable VHD of virtually any size is only the size of the info contained into it.

 

2 - Then loading on Ram and full booting fime should be the same.

 

3 - Having such amount of Ram unused is just a waste of money.

 

If I would want to always Ramboot (and exceptionally Fdisk boot) I would make an expandable wimboot VHD of 4 GB for PCs with 8 GB Ram (as mine). 

 

Just try this as a guide if you have more than 4 GB of Ram the size of your expandable VHD may be 1/2 of your installed Ram.

 

This DO NOT apply to PCs with a minimum of 4 GB of Ram, for this case I recommend a VHD of maximum 1.5 GB.

 

alacran

 

 

alacran



#70 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 25 March 2019 - 12:30 AM

Exactly, I do know u said exactly the opposite, not me. My experience here is different from yours there. what u suggest for pcs whose ram is lower than 4gb I experience as being convenient for high end pcs, whereas it is just low-end pcs with little ram and most of all with not so powerful cpus that require bigger vhds. I also told u what i do with excess ram (hd caching).  do u have a high end pc to test what u say? I do to test what I say. As for why i get what I get as results, i will certainly leave it up to u experts. but u cannot claim the opposite of what happens here. I repeat, the only thing that is slow here is booting, which is still quicker now than it was when I had your recommended sizes, before the wimboot era. Everything has never been so quick as from wimbooting with small sizes on. 



#71 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 25 March 2019 - 12:54 AM

Now, to substantiate and corroborate what I last said, I can tell u I tested it again with 4gb dynamic vhd: do u know the only different thing it does? occupy more ram as a result of having ramloaded it, nothing else. and if u think that it occupies just the used space on account of the counting being truncated at end of used space, no matter how big u make the vhd, u r wrong, check with resmon.exe and see that it occupies the portion of ram equal to the full size of the vhd. to what avail? none at all. check it urself if u do not believe me. u r correct in one thing. the preloading times are the same, so are the full loading times. exactly the same, 24 secs traditional bootmgr, 30 secs ramdisk g4d. so what is the point in having a bigger vhd? occupying more ram for nothing? boh.



#72 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 25 March 2019 - 04:28 AM

Wonko the Sane, on 24 Mar 2019 - 03:52 AM, said:

Yep, thanks :), but:
1) WHY (the heck)?
2) WHY (the double heck) it was not written in the log, I mean it seems to me like a non-trifling change (that probably makes it so that every later release won't work)

:duff:
Wonko


yaya fixed it.

download the latest build http://grub4dos.chenall.net

the 2 lines were commented out by mistake.

added a line of bytesread = bytesread to suppress gcc unused variable warning.
  • alacran likes this

#73 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 March 2019 - 09:30 AM

yaya fixed it.

download the latest build http://grub4dos.chenall.net

the 2 lines were commented out by mistake.

added a line of bytesread = bytesread to suppress gcc unused variable warning.

Thanks :), good news.

 

@alacran

Yes, but what is the increment?

100-150 MB? (certainly NOT the full size of the .vhd)

To which files is it due?

I.e. make a DIR /S before ever booting and after having FileDisk booted.

Do "new" files appear or existing ones grow?

 

@antonino61

Somehow you are "disconnected" from alacran experiments and experience. :dubbio:

alacran reports RAMdisk booting times of around 30 seconds for "static" .vhd and around 4 seconds  for "dynamic" ones.

You are seemingly reporting RAMdisk booting times of around 30 seconds for "static" .vhd and the same around 30 seconds  for "dynamic" ones.

From the outside it seems clear to me that either one of you is lying :w00t: :ph34r: or - more simply :) - you are not using EXACTLY the same method to EITHER make the .wim and .vhd OR to boot it.

Now, though it is not at all important whether the base issue is alacran completely failing to explain in detail, extensively and fully what he is doing or you completely failing to replicate it exactly, until you two somehow manage to communicate the whatever needed info it seems a conversation between deaf people.

 

:duff:

Wonko


  • blackbalfur likes this

#74 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 25 March 2019 - 10:06 AM

No, Wonko, no. Different hardware, different situations, different needs. My difference is only 4 secs overall; alacran's concerns only preramloading. thanks

#75 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 25 March 2019 - 10:29 AM

My 4sec difference refers to conventional bootmgr filedisk booting vs g4d ramdisk booting (30 vs 24 sec respectively). Alacran's point refers only to the preramloading stage (the counting u c at the outset). Neither is lying. To what avail would we?





Also tagged with one or more of these keywords: wimboot, ramboot, lzx, gzip, lz4, vhd

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users