Jump to content











Photo

[GRUB4DOS] Any alternate solution to map 7GB.vhd.GZ on RAM?


  • Please log in to reply
8 replies to this topic

#1 L A M A

L A M A

    Silver Member

  • Advanced user
  • 540 posts
  •  
    United Nations

Posted 23 April 2013 - 08:51 AM

Since long time, a compressed 7GB.VHD.GZ (2.07GB) cannot be mapped on RAM as it gives following error on screenshot. Is there any alternate solution to map 7GB.vhd.GZ on RAM?

 

The goal here is to have huge free space for the %SystemDrive%, less time to map on memory and, have less I/Os with physical disk.

 

20130423_135743_opt.jpg



#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 April 2013 - 03:59 PM

How EXACTLY did you create that .vhd?

From the screenshots it seems A LOT like a SPARSE .vhd (compressed or not to .gz), AND additionally, the error 17 indicates that something is not valid in the filesystem in it.

 

:cheers:

Wonko



#3 L A M A

L A M A

    Silver Member

  • Advanced user
  • 540 posts
  •  
    United Nations

Posted 24 April 2013 - 08:06 AM

I used Win7 toolkit to shrink Win7x86 ISO size, installed on partition then, installed FiraDisk driver, removed \DosDevices\C: from Mounted devices, rebooted to XP, copied Win7x86 files to 7GB.VHD and fixed BCD from bootice.

 

VHD_XP_Create.exe created 7GB empty VHD.

gzip.exe -1 7gb.vhd command created 7gb.vhd.gz

 

 

similarly, I used the same command for 3.9GB.vhd (which also created .gz file) for XP.

 

 

In Menu.lst
title Microsoft Windows 7 x86 Ultimate Edition (FiraDisk GZ RAM 7GB)
find --set-root --ignore-floppies /Win7-1.vhd.gz
map --mem /Win7-1.vhd.gz (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 

 

 

3.9GB.vhd.gz works exactly as expected but 7GB, 10GB etc never worked in past. And as usual, .gz decompression speed also sucks big time but, I'd rather not go there (for now). 

 

BTW, 7GB.VHD works fine with grub4dos however 7GB.VHD.GZ does not work. My guess is, any gzip file above 4GB doesn't work with grub4dos.

 

On a 120MiB/s hdd, gzip decompresses at 11MiB/s where data is compressed and Approx 40MiB/s where there is free space in image. Boot ups are suppose to be fast yet, fastest decomperssion format is NOT implemented in grub4dos (this always sucked). Years have gone by... :hmm:



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 April 2013 - 08:56 AM

Once set aside your sounding like an ungrateful little bastard towards the good grub4dos developers you could try a 4.0 and a 4.1 Gb images to verify that a limit exists.

Then it could be an issue connected to the size of the image (once expanded) or to the size of the image (compressed)  or to the amount of memory needed in the process.

 

From your screenshot grub4dos "sees" an image of size 5947393 sectors which means 5947393 * 512 = 3,045,065,216 bytes, while the data in the MBR partition table is read as 14333951, i.e. 7,338,982,912 bytes.

Most probably the first is the image size once compressed (but you talked of 2.07 Gb :unsure:), and the latter is the correct size of the image once expanded, i.e. grub4dos fails to "see" the decompressed size.

 

As I see it - besides finding where the limit/size issue lies (and hope that the good grub4dos developers may fix it in a fuure release) - you are however using the tools outside (or beyond) their intended scope.

 

I cannot even imagine :ph34r: WHY exactly one would want/need an 8 Gb image loaded in RAM :dubbio:, but the "right" approach IMHO is to separate the setup in a small, efficient image dedicated to boot the system and another smallish image mounted with IMDISK and expanded to the size you need it.

You can use a mount point and thus the "system" drive will be as large as you need it.

 

:cheers:

Wonko



#5 L A M A

L A M A

    Silver Member

  • Advanced user
  • 540 posts
  •  
    United Nations

Posted 24 April 2013 - 12:25 PM

Once set aside your sounding like an ungrateful little bastard towards the good grub4dos developers 

 

:cheers:

Wonko

:rofl: Obviously I mean no dis-respect to great grub4dos developers and their work done thus far (other improvements etc and all) but when it comes THIS issue and decompression speed, it looks opposite of what you said, which is:

Ignorant and Lazy developers continue to treat users as ungrateful little bastards and fix only what they find worthy. :P

 

I freshly created 3 image files and Gzipped it while its empty

01. 3.5GB                 became 15.7MB

02. 4.0GB (not 3.9)   became 17.8MB

03. 4.8GB                  became 21.9MB

 

As usual 3.5GB got mapped in 6sec :hyper: and other two with =<4GB showed that screen shot error.

 

 

As to why one would want 8GB+? my first post answers this specifically for me, more for %SystemDrive% but one should not try to guess other user's motives. Size is expected to get bigger as user tends to install, update, upgrade etc. These days programs are so bloated, you know it already... Besides, if a user can use 8GB or 16GB without compromising speed then, why not???

 

My previous post's 40MB approx speed of empty free space decompression is now proved wrong with this latest test above however, data decompression definately sucks (and NOT only in grub4dos but also in windows). Any codec that compresses fast, can also decompress fast. Since I've not done latest research on which codec is fastest, I'll remain stuck to my previous findings (years back) .LZO

 

edit: Syslinux already supports lzo, why can't grub4dos??? One cannot copy paste some codes :P I'm no coder 



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 April 2013 - 02:06 PM

I don't get it. :unsure:

If you map something in RAM it is volatile.

Why don't you use direct mapping instead of mem mapping?

There will be no need for compression/decompression and no time to transfer the image in memory (at the slowish transfer speed grub4dos allows).

 

Your statement about compression algorithms  is (frankly) pure bu**sh*t :w00t:, every algorithm is a trade off between:

  1. compactness of result (tightness of compression)
  2. compressing time (processor resources)
  3. expanding time (processor resources)
  4. memory (RAM) used in both compressing and expanding

 

Most currently used compression tools tend to be - within limits - "symmetrical" i.e. to take more or less the same time/resources in compressing and in expanding AND to need a limited amount of RAM.

This is of course meant to allow portability and "general use".

You might be interested in reading:

http://mattmahoney.net/dc/dce.html

 

Just for fun, compare:

http://heartofcomp.a...rg/MOC/MOCA.htm

the results of a Asymetrical compressor such as flashzip:

 

 

 

10 flashzip v. 1.1.2 863181145 497.57 98.37 38508 35314 36911 a -r -s -mx3 -k7 -b25
11 flashzip v. 1.1.2 869090850 409.06 98.44 38036 35551 36793 a -r -s -m3 -k7 -b256
12 flashzip v. 1.1.2 - F.A. NANIA[ITA] 870805694 289.05 70.04 37145 35393 36269 a -r -s -b128 -mx3 -k
13 flashzip v. 1.1.2 - F.A. NANIA[ITA] 875927550 165.17 39.56 36358 35354 35856 a -r -s -b64 -t4 -mx3
14 flashzip v. 1.1.2 877465663 270.37 117.64 37262 36040 36651 a -r -s -m0 -k7 -b256

 

or 7-zip:

 

 

 

18 7ZIP v. 9.20 - Igor Pavlov[RUS] 893981987 530.83 42.04 40006 36096 38051 a -mx9 -mmt8 -m0=lzma
19 7ZIP v. 9.20 - Igor Pavlov[RUS] 899004950 432.12 41.20 39417 36290 37853 a -m0=lzma2 -md48m -m

With some for gzip:

http://tukaani.org/l...benchmarks.html

gzip is already asymmetrical  with a ratio (roughly) 3:1 in compression:expansion times, nanozip has around 5:1 and 7-zip (see above) has around 10:1, but RAR (proprietary) is faster (in absolute decompression times), one could "risk" a lesser known compressor like ZHUFF, roughly 13:1, lower compression ratio but blazingly fast in expanding:

 

 

32 ZHUFF v. 1.3b - Yann Collet[FRA] 1032461792 156.29 12.21 43799 41494 42646 -c2t8s 

 

The idea of using a "better" compression algorithm is not new, example here:

http://reboot.pro/to...xz-compression/

but evidently has a lower priority than other in the development of grub4dos.

BTW, since now grub4dos has the possibility of running external programs, you may code your own (highly Asymmetrical) compressor/decompressor alright, if you are not satisfied with the decisions/activities/work of the good grub4dos developers.

 

:cheers:

Wonko



#7 L A M A

L A M A

    Silver Member

  • Advanced user
  • 540 posts
  •  
    United Nations

Posted 24 April 2013 - 03:40 PM

My ultimate goal was fastest map mem booted OS with fastest operational speed, dont' know why you suggest me to go for direct mapping. RAM being volatile is in fact an advantage, any unwanted changes gets wiped with one reboot. 

 

:huh: Why do I get the feeling that you're:

01. Against (progress, improvement, changes, development) 

02. Defending Developers

03. Not a developer in the area of grub4dos

04. After my @$$ (calling me a Bad word), because I ®aped your wife (and you get away with it...) :rofl: 

 

 

I'm trying to speed up an area of development which has been ignored for... quite some time. Your replies make it look as if it's a bad thing to do. Is it really bad to have fastest decompression implemented because it goes against your agenda? You will not miss one chance to twist my words and get me off the topic :huh: 



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 24 April 2013 - 04:43 PM

Not at all, I am very much in favour of new developments and better things :), but I try to avoid accusing other people (which try to help, or develop in any field) of being unresponsive.

I find that anyone providing (for free) their time to something and sharing the results should be thanked for whatever they do provide (even if it is not exactly what you want, need or think you need) and whining about them not following your agenda (i.e. fulfilling your desires/wishes/needs) to be a form of lack of gratitude towards them.

 

But this topic (I may be wrong about it, of course) is/was about you having a problem with mapping a largish .gz compressed image to mem in grub4dos.

 

This is a technical problem that you decided to tackle by modifying grub4dos (actually have someone fix it ) and/or adding to it new features (again having someone else adding those features), and since noone is probably going ("at all" or "in a timely fashion") to fulfill your desires, whine a bit about it.

 

What I tried (vainly) to tell you is that the people that may do that are developers that use their own free time in the development and that may or may not solve that issue and/or add those new features and/or manage to do so in a timely fashion or not before several days/weeks/months/years.

 

So, pragmatically, I attempted (vainly) to provide you with a workaround, BTW perfectly tested and working since years, of dividing the largish image into two images, a smaller, smallish one to be actually mapped to mem through grub4dos and a second one to be later mounted in the SAME FILESYSTEM as the first one (through a mountpoint) by the booted OS.

 

Such a solution:

  1. is working since years (thus it is immediately available)
  2. fulfills (seemingly) your actual requirements (have an 8 Gb or larger image "volatile" in memory)
  3. should be additionally faster in boot time

Just like the recent "delay in boot time" thread here:

http://reboot.pro/to...tes-to-connect/

you are extremely reluctant to follow advice (after having asked for it) let alone thank someone for the time spent in attempting to provide it.

 

The reference to raping my wife (or any other living being for that matters) is not fun, really not fun, but of course your bad taste being third-rate or worst is in the eye of the beholder.

 

The good news are of course that if you were looking for a way to have me never reply again to your threads, you found it.

 

Roger, out.

 

:cheers:

Wonko

 

 

 

 



#9 L A M A

L A M A

    Silver Member

  • Advanced user
  • 540 posts
  •  
    United Nations

Posted 24 April 2013 - 06:54 PM

That reference only meant as if you were taking it very personally to make a fool out me everytime but you took it very.... sorry about that. (I read someone else talking like that so, it looked funny at that time) but, guess i'm wrong.

 

 

I thought you were comfortable using the "b" word so,... i sort of tried to reply in the same sense. I guess its definately not in me make bad word sound fun the way you do...  :blush:

 

 

 

I still mean no dis respect to you or any developers  :lightbulb: also, your replies are as always very informative, i admit, my head cannot absorb things that fast when you throw me off my track... but...


  • pscEx likes this




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users