262 replies to this topic

[alacran]

@ wimb

 

 

VHD_W8C_87 is not meant to be used to reduce size of 10 x64 installed in VHD.

That will not work.

 

The program VHD_W8C_87 is compatible with Win 10 OS means that you can use the program in Win 10 OS

to make Portable 8  Or Mini 8 VHD from source VHD with fresh installed Win 8.1

 

My mistake, it is obvious I missunderstood this.

 

 

Now to solve your trouble:

 

Use R-mouse to Open Administrator Command Window

To check NTFS filesystem on drive C: D: and E: use

chkntfs C: D: E:

It shows you which drives are dirty

 

To repair NTFS filesystem on drive C: use

chkdsk /F C:

And do this also for the other dirty drives

 

Thanks. It is not urgent right now anymore, but I will keep this info for future troubles, as 10 is very prone to mark the dirty bit on HD.

 

Also thanks for the info for Ram booting through grub4dos a WIMBOOT Install of Win10x64 in VHD in your previous post, it is in fact a little tricky, I'm glad you found the way to make it work.

 

alacran

[wimb]

Also thanks for the info for Ram booting through grub4dos a WIMBOOT Install of Win10x64 in VHD in your previous post, it is in fact a little tricky, I'm glad you found the way to make it work.

 

 

Booting from RAMDISK with Win10x64 in WIMBOOT VHD was a funny experiment.

 

Better and a very convenient solution is Win10XPE WIM file Size = 775 MB for booting from RAMDISK

It is a single WIM file that can be located everywhere, whereas the Win10x64 WIMBOOT VHD solution has 2 files and is not portable.

 

Win10XPE includes AOMEI Partition Assistant and Macrium Reflect to make Backup Image.

 

Win10XPE WIM file is booting in UEFI Secure and in BIOS mode from Windows Boot Manager Menu,

whereas in case of VHD and SVBus driver booting with Grub4dos then you are limited to BIOS mode only.

 

Win10 x64 installed in 25 GB VHDX by WinNTSetup is the most interesting solution and allows booting as FILEDISK.

Such VHDX allows you to install any program and to use printers and it boots from Portable SSD very fast on any hardware in BIOS and UEFI Secure mode.

It is a universal learning system that contains far more drivers than Win 8.1 and in case of 10 x64 booting from USB and USB 3.0 is supported out of the box.

[alacran]

@ wimb

 

 

Booting from RAMDISK with Win10x64 in WIMBOOT VHD was a funny experiment, but it has no practical value for me.

 

Better and a very convenient solution is Win10XPE WIM file Size = 775 MB for booting from RAMDISK

It is a single WIM file that can be located everywhere, whereas the Win10x64 WIMBOOT VHD solution has 2 files and is not portable.

 

Yes, you are right, a good WinPE is always smaller and boots faster, I'm totally agree and it's my prefered option, but this do not decrease in any way the merit of your experiment to RamBoot a 10x64 VHD wimboot mode install, AFAIK nobody has done it before, my friend.

 

 

Win10 x64 installed in 25 GB VHDX by WinNTSetup is the most interesting solution and allows booting as FILEDISK.

Such VHDX allows you to install any program and to use printers and it boots from Portable SSD very fast on any hardware in BIOS and UEFI Secure mode.

It is a universal learning system that contains far more drivers than Win 8.1 and in case of 10 x64 booting from USB and USB 3.0 is supported out of the box.

 

I have since about 6 months ago two Win10 VHDs (a 1709 x64 and a 1809 x86 [this is LTSC 2019 on 6.5 GB, full install, + FireFox, 1.5 GB free]), working very fine, (updates blocked, this may be the reason). Also have available a 120 GB SSD that I may use for this, just need to buy a new disk case for it.

 

As always it is a pleasure to talk with you.

 

alacran

[alacran]

After making a new 10x64 1809 full install, (of course no AV, no pagefile and no swap file) on a 10 GB VHD (not compressed) located on a partition of my MBR HDD, latter installing 7z, Classic Shell, CCleaner and puting several Portables on documents folder, still has 2.49 GB free.

 

EDIT: Forgot to say it is also installed Word and Excell from Office 2003 + compatibility package to read/write Office 2007 and following formats.

 

Then I made a wimboot capture (10x64-WB.wim file is 3.95 GB) and a new wimboot install on a 1 GB VHD (located on internal HDD) having 662 MB free yet, so OS and format is consuming only 362 MB, this is after booting from it.

 

All done upto now using only wimlib-clc and BootIce for editing BCD.  So far only Windows boot manager is used, not tested RamBoot yet.

 

I think now run a 1 GB (or maybe 512 MB) 10x64 VHD on RAM looks a little more attractive. Win10XPE_x64.ISO is 742 MB.

 

Now I need to move the wimboot VHD and the source 10x64-WB.wim file to an external device, I could use a 120 GB SSD as wimb suggested, but I would prefer something more compact as a High Speed U1 SD or MicroSD card on a USB 3.0 adapter as I'm using for my UEFI MULTI up to now.

 

alacran

Attached Thumbnails

• 

[alacran]

This is what I got when I made a 512 MB 10x64 wimboot VHD hard linked to source 10x64-WB.wim file of 3.95 GB:

 

387 MB used and 123 MB Free, from 510 MB available. See attached picture.

 

By the way on previous post forgot to say it is also installed Word and Excell from Office 2003 + compatibility package to read/write Office 2007 and following formats.

 

Well now it is even smaller than Win10XPE_x64.ISO = 775 MB or Win10XPE_x64 boot.wim = 718 MB

And it has also the best and FREE tools to capture/deploy *.wim files (usefull for make/recover backups too), as wimlib-clc and WinNTSetup.

 

Next will be to put this 512 MB VHD on a portable device and see how it boots.

 

Wimb procedure to make it Ram Bootable is a little tricky, I will try to follow it after booting normally with Windows bootmanager from a portable USB device.

 

alacran

Attached Thumbnails

• 

[wimb]

This is what I got when I made a 512 MB 10x64 wimboot VHD hard linked to source 10x64-WB.wim file of 3.95 GB:

 

387 MB used and 123 MB Free, from 510 MB available. See attached picture.

 

 

Very nice reduction in size again. Very GOOD   

 

It will be interesting if you can make it portable e.g. booting from RAMDISK and as FILEDISK from such small WIMBOOT VHD + WIM file  located on portable SSD.

 

Did you do any special things besides the things I know and  do already to get this impressive size reduction ?

[alacran]

I'm starting a new thread for this topic, I wouldn't like to keep hijacking your thread anymore, and now also think the subject deserves its own thead to keep all info together and let other people find it easier, hope you can visit it to see the little details if you want deeper info, and also to help me with RamBooting, as I am specting some troubles with it.

 

So far the new thread is under costruction, it will be ready very soon.

 

EDIT: This is topic Making the smallest Win10 install (wimboot mode)

 

By now I have USB booted from the VHD and source .wim  located both (to be totally portable) on same secondary NTFS partition of a USB 2.0 device, (AData UV100 32 GB), it feels as slow like old times booting my first BartPE from a CD, it took about a minute or maybe a minute and a half to get desktop, once there and after waiting about 20 seconds the task manager showed no more disk activity and all was a little slow but fine.

 

This USB 2.0 device is about 24 to 25 MB/sec in reading and writting speed, wich is not bad for a USB 2.0, My MicroSD Kingston with an USB 3.0 adapter is capable of upto real 74 to 75 MB/seg reading speed but only about 14 to 15 MB/seg writing speed, this are real speeds I have observed during real files transfer on daily tasks.

 

Of course once RamBoted all will be very fast, By now my system is consuming about 800 MB, but will check carefully.

 

 Have you seen how much Ram is consumed when you RamBoot your wimboot VHD?, I'm on an old I3 with 8 GB RAM, hope this can be enought, but would like to make sure.

 

EDIT: This time I made the VHD on my MicroSDHC 32GB UHS-I Kingston SDCS/32GB CL10, 80R (Canvas Select) connected with my USB 3.0 adapter to a USB 2.0 port and it took only 48 seconds to reach desktop, and all was working very fine OS do not feel slow.

But I would reccomend you to better buy the new Kingston model Canvas Go! with 90 MB/sec on reading speed and 45 MB/sec on writing speed.

 

alacran

[wimb]

I have succeeded in making it portable.

 

Now I have WIMBOOT VHD + WIM file located on USB and booting from RAMDISK

 

As you can see From 13.9 GB Free RAM there is 1.4 GB in use and 12.5 GB available

 

==  ==  == 

title W10x64_W82.vhd - SVBus  RAMDISK  - 2048 MB - map as hd3
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd (hd3)
map --hook
root (hd3,0)
chainloader /bootmgr

The issue is that you need to map the VHD in RAMDISK as the real Windows Disk number of the location of the Backing WIM File, in my case hd3

I have in my computer three internal harddisks - the SSD is hd0 and my USB-SSD gets number hd3

 

What will be a better menu.lst entry so that the VHD in RAMDISK is always mounted as the real Windows disk number of the Backing WIM file ?

[alacran]

Isn't this good enought, having the VHD and source .wim on same partition?:

 

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd
map --hook
chainloader /bootmgr

[wimb]

Isn't this good enought, having the VHD and source .wim on same partition?:

 

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd
map --hook
chainloader /bootmgr

 

this does NOT work, but I will try to find a solution.

 

Hopefully Wonko or steve6375 can help to find a solution ....

[alacran]

This could have been a nightmare for all people having more than one internal disk as myself if you haven't found it.

 

I have 2 internal HDDs on this desktop so on grub4dos I should have for this PC a menu like this one:

 

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB - map as hd2
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd (hd2)
map --hook
root (hd2,0)
chainloader /bootmgr

 

But also have other PCs with single disk, so at least for now I will need 2 diferent Titles on my menu.lst

 

And what are your BCD(s) entries into Boot\BCD and the other on  efi\microsoft\boot\BCD?, Could you post a picture of one of them opened in easy mode from BootIce please?

 

I assume after installing the SVBus driver as it is unsigned we need to use Test Mode and No integrity checks. But since you have allready booted it, it is easier to ask.

 

I want to avoid me troubles as much as possible. Thanks in advance.

[wimb]

You need in BOOTICE to Add New entry AllowPrereleaseSignatures "Yes"

I did that for the USSD Boot\BCD and also for the VHD Internal Boot\BCD file

 

For EFI booting as Filedisk with Microsoft driver this is not yet sufficient and I need to use then F8 in Boot Manager menu to Allow unsigned driver

 

[blackbalfur]

I have succeeded in making it portable.

 

Now I have WIMBOOT VHD + WIM file located on USB and booting from RAMDISK

 

As you can see From 13.9 GB Free RAM there is 1.4 GB in use and 12.5 GB available

 

W10x64_W82-Portable-2019-02-24_093657.png == W10x64_W82-Portable-2019-02-24_093935.png == W10x64_W82-Memory-2019-02-24_101035.png == W10x64_W82-Disks-2019-02-24_103303.png

title W10x64_W82.vhd - SVBus  RAMDISK  - 2048 MB - map as hd3
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd (hd3)
map --hook
root (hd3,0)
chainloader /bootmgr

The issue is that you need to map the VHD in RAMDISK as the real Windows Disk number of the location of the Backing WIM File, in my case hd3

I have in my computer three internal harddisks - the SSD is hd0 and my USB-SSD gets number hd3

 

What will be a better menu.lst entry so that the VHD in RAMDISK is always mounted as the real Windows disk number of the Backing WIM file ?

 

What i do is making more entries.
 

So not only hd3 but also hd0 up to let say hd5.

 

When an entry does not work you will get back to the screen where you can choose again in seconds.

 

just try untill you get the one that works for your PC and harddisk setup.

 

I know not ideal but at least it works fast.

[Wonko the Sane]

I am not sure to understand the problem.

 

If the .vhd is on the same (physical) hard disk (or hard disk like device) can't one parse the output of the root command?

 

I mean, after:

find --set-root --ignore-floppies /W10x64_W82.vhd

the output of the root command will be (say):

(hd2,0) .....

So:

root | set myroot=
set mypart=%myroot:~0,7%
set mydisk=%myroot:~0,4%)
set mydisk
set mypart

Should be good for hard disks (and partitions) 0 to 9 (I know that someone will soon be posting that he/she has 10 or 11 hard disks or 10 or 11 partitions on the disk where he/she puts the .vhd ....)

 

Wonko

[wimb]

The point is that after booting from RAMDISK then Windows has to find the Backing WIM file.

This Backing WIM file is only found when the VHD from USB loaded into RAM is mounted with disk number

corresponding to the disknumber that Windows will give the USB device where the WIM Backing file is located.

 

In my case I have 3 internal harddisks that Windows will number as hd0, hd1, hd2

My USB device gets in Windows number hd3

 

So when I ask Grub4dos to mount the VHD into RAMDISK as (hd3) then the WIMBOOT VHD when booting is able to find the Backing WIM file on hd3

 

In all other case e.g. mounting as hd0 then after loading into RAMDISK then booting fails with Error 225 which means file not found.

 

@blackbalfur

Your solution does not work for WIMBOOT

After loading into RAMDISK or after trying to boot as FILEDISK you get Error 225 and cannot return into Grub4dos menu

 

@jaclaz

In Grub4dos I can determine the root where my VHD is located with your proposal.

But what I need is to set in Grub4dos menu the disknumber that the device will get as given by Windows when booting from RAMDISK

So for my configuration I have it working.

But when I will try to boot from RAMDISK on machine with two harddisks then I have to use hd2 instead of hd3.

You can of course have several menu.lst entries, but using them will then quite often result in Error 225 after loading the RAMDISK followed by boot failure needing Reset.

[Wonko the Sane]

The point is that after booting from RAMDISK then Windows has to find the Backing WIM file.

This Backing WIM file is only found when the VHD from USB loaded into RAM is mounted with disk number

corresponding to the disknumber that Windows will give the USB device where the WIM Backing file is located.

 

In my case I have 3 internal harddisks that Windows will number as hd0, hd1, hd2

My USB device gets in Windows number hd3

 

So when I ask Grub4dos to mount the VHD into RAMDISK as (hd3) then the WIMBOOT VHD when booting is able to find the Backing WIM file on hd3

Yep , and IF the .vhd is on (hd3) the proposed snippet will work just fine.

Expanded, yours, hardcoded to (hd3):

title W10x64_W82.vhd - SVBus  RAMDISK  - 2048 MB - map as hd3
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd (hd3)
map --hook
root (hd3,0)
chainloader /bootmgr

proposed:

title W10x64_W82.vhd - SVBus  RAMDISK  - 2048 MB - map as hd3
find --set-root --ignore-floppies /W10x64_W82.vhd
root | set myroot=
set mypart=%myroot:~0,7%
set mydisk=%myroot:~0,4%)
map --top --mem /W10x64_W82.vhd %mydisk%
map --hook
root %mypart%
chainloader /bootmgr

Of course feel free to make any needed changes/variations.

 

Wonko

[wimb]

Thanks Wonko for your proposed menu.lst entry.

 

It does not work as published but it will be helpful for me to parse grub4dos output and to set values in the entry.

 

When I do just the grub4dos command find then I get the list of hardisks and partitions.

What I need  to do is to parse the output and to get the hd number of the last entry.

That is in fact the number that I must use in the menu.lst entry

[Wonko the Sane]

Thanks Wonko for your proposed menu.lst entry.

 

It does not work as published but it will be helpful for me to parse grub4dos output and to set values in the entry.

 

When I do just the grub4dos command find then I get the list of hardisks and partitions.

What I need  to do is to parse the output and to get the hd number of the last entry.

That is in fact the number that I must use in the menu.lst entry

No you don't.

 

I don't understand why the posted example wouldn't work.

 

I CLAIM that IF the .vhd is on (hd3,0) the posted proposal will output EXACTLY THE SAME of your hardcoded entry (that you reported as successful), namely

set mydisk 

will output

(hd3)

and

set mypart

will output

(hd3,0)

so, if it doesn't work it means that also your original hardcoded one doesn't work

 

Maybe you could post the actual output of 

set mydisk

and

set mypart

on your system (the SAME one where the hardcoded (hd3) and (hd3,0) work).

 

 

WHAT is the ACTUAL info you want to get?

 

Last disk?

 

Last disk is (hd-1).

I.e.

the disk is (hd-1)

first partition on it is (hd-1,0)

i.e.:

 

 

 

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB - map as hd3
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

Is that what you want?

 

Wonko

[wimb]

 

WHAT is the ACTUAL info you want to get?

 

Last disk?

 

Last disk is (hd-1).

I.e.

the disk is (hd-1)

first partition on it is (hd-1,0)

i.e.:

 

Is that what you want?

 

Wonko

 

Excellent solution   

 

That works very good .

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find --set-root --ignore-floppies /W10x64_W82.vhd
map --top --mem /W10x64_W82.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

[alacran]

@ wimb

 

After making some experiments in order to Ramboot a VHD installed on Wimboot mode, IMHO this is a better option for your menu.lst, (to make it more suitable for this project):

iftitle [if exist (hd0,0)/8.1x64ESP1-WB.vhd] 8.1x64ESP1-WB.vhd - SVBus RAMDISK - 1024 MB - map for WIMBOOT
map --top --mem (hd0,0)/8.1x64ESP1-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

iftitle [if exist (hd0,1)/8.1x64ESP1-WB.vhd] 8.1x64ESP1-WB.vhd - SVBus RAMDISK - 1024 MB - map for WIMBOOT
map --top --mem (hd0,1)/8.1x64ESP1-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

iftitle [if exist (hd0,0)/10x64-WB.vhd] 10x64-WB.vhd - SVBus RAMDISK - 1024 MB - map for WIMBOOT
map --top --mem (hd0,0)/10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

iftitle [if exist (hd0,1)/10x64-WB.vhd] 10x64-WB.vhd - SVBus RAMDISK - 1024 MB - map for WIMBOOT
map --top --mem (hd0,1)/10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

Also good for external USB devices with one or two (MBR/legacy) partitions, and also helps to tests if grub4dos can access or not a secondary NTFS partition on your actual device, a problem I had, as grub4dos can't acces files on secondary NTFS partition of my  MicroSDHC 32GB UHS-I Kingston SDCS/32GB CL10, 80R (Canvas Select) connected with my USB 3.0 adapter , some internal driver used into the MicroSD or the adapter is not fully compatable with the very last version (2018.12.22) of grub4dos, tried other versions but same thing.

            

I can run the VHD with Windows bootmanager from second partition, of course not as Ramboot so secondary partition is seen on Windows, but nothing from second NTFS partition can be booted with grub4dos, I was forced to make a second MicroSD with a single NTFS primary partition (it was good I had 3 of them available) in order to be able to Ramboot this VHD (it takes a minute and 48 seconds to load 1 GB in Ram and reach desktop, and it was pluged to a USB 2.0 port on PC [my mistake]). I can reduce the size of VHD to 512 MB and it will be loaded in half time + the time to reach desktop. But to me it doesn't seems excesive as it is now.

 

Of course there are many factors involved here, the USB device reading speed, the CPU speed and Ram speed, so every case will be unique.

 

But from another device, an Adata UV100 USB 2.0 stick with 2 partitions (only empty stick avilable at the time) I have no problem to Ramboot the VHD and it works flawlessly once loaded on Ram but of course it takes longer to load in Ram, just wanted to confirm on other devices can work fine.

 

EDIT: Fixed some typing mistakes (thanks to wimb for find them), please excuse me but it was about 4:00 am in my country when I made the lines this way first time for my menu.lst, and as they worked fine (even with mistakes), just copy paste here and never reviewed them again.

 

alacran

[wimb]

 

After making some experiments in order to Ramboot a VHD installed on Wimboot mode, IMHO this is a better option for your menu.lst, (to make it more suitable for this project):

 

Thanks alacran,  that is a good idea to use iftitle and avoid find in menu.lst entries. 

 

There is a new version of UEFI MULTI available with new grub4dos SVBus menu entries using iftitle

and for booting from USB using (hd-1) for mapping for WIMBOOT

 

In case of VHD and WIM file located on USB NTFS partition we use:

iftitle [if exist (hd0,1)/W10x64_S3.vhd] (hd0,1)/W10x64_S3.vhd - SVBus  FILEDISK - 2048 MB - map for WIMBOOT
map (hd0,1)/W10x64_S3.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

iftitle [if exist (hd0,1)/W10x64_S3.vhd] (hd0,1)/W10x64_S3.vhd - SVBus  RAMDISK  - 2048 MB - map for WIMBOOT
map --top --mem (hd0,1)/W10x64_S3.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

In VHD WIMBOOT we have a two file Operating System, where first grub4dos loads the VHD into RAM.

When booting from RAMDISK as WIMBOOT, then Windows has to find the location of the Backing WIM file.

In grub4dos the USB Boot disk with our VHD and WIM files on NTFS partition has the lowest disk number hd0

but Windows will give the same USB disk the highest disk number.

This highest disk number strongly depends on the number of internal harddisks and varies from one computer to another.

 

That is why I am so happy with the solution given by Wonko to use (hd-1) as value for the highest disk number which is valid for all configurations 

 

When the VHD booting from RAMDISK is mapped as (hd-1)  then it is always able to find the Backing WIM file on USB 

 

In this way we have a portable reliable full Win10x64 Operating System on USB booting very fast from RAMDISK and that it will not change e.g. by malware.

 

VHD size 2 GB with full Win10x64 OS + Office Word and Excel + VLC player total size 600 MB in RAMDISK connected to WIM file of size 6 GB on USB NTFS drive

As compared to WinPE the VHD WIMBOOT has the advantage to have support for Office and Printer and any program can be installed which is all not the case for WinPE.

 

==  ==  ==  ==  == 

 

[alacran]

@ wimb

 

Good, well done, you are the man who Rambooted the first time a full wimboot Windows 10 OS, (and I think I'm the second, HA, HA, HA).

 

There is something I want to comment to you, take a carefull look at your second picture on your last post, your VHD first sector is 64.

 

I know this does not seems very relevant but it increase the wear on Solid State devices.

 

I found Windows, WinNTSetup and also BootIce sometimes/manytimes create VHDs with an starting sector different (to the usual) 2048 on external drives see:

 

 

You can use any good partition tool as PartitionGuru Free edition to partition your disk as required, also BootIce can do it but I allways prefer to do it with PartitionGuru as BootIce and Windows 7, 8.x, (haven't tested 10) when making small partitions on VHDs located on USB sticks have the tendency to do not use 2048 as first sector as usually done by OS, they sometimes use 63 or 128 and PartitionGuru allways uses 2048 (but can be changed if required) as starting LBA and automatically make the first partition MBR 6.x and activate it, also installs bootmanager PBR on it and on second partition too.

 

From this post: http://reboot.pro/to...hd/#entry209488

 

alacran

[wimb]

There is something I want to comment to you, take a carefull look at your second picture on your last post, your VHD first sector is 64.

 

I know this does not seems very relevant but it increase the wear on Solid State devices.

 

I found Windows, WinNTSetup and also BootIce sometimes/manytimes create VHDs with an starting sector different (to the usual) 2048 on external drives see:

 

 

Probably I can adjust settings in WinNTSetup to Create VHD with other value of partition first sector.

 

I was not aware of the possible wear problem for SSD, so I have to study on that subject.

 

Anyway I used tinyhexer and saw that actually the first partition sector in that VHD is sector 128  which I think is normal for VHD's

 

I doubt that there is a wear problem since the value of 128 is an internal VHD count and  the USSD hosting the VHD has partition first sector on 2048

[Wonko the Sane]

Hold your horses.

 

Let's debunk these myths at their very start.

 

The "new paradigm" (re:offset of partitions) is (as often happens with anything MS originated) more myths than anything else.

 

The idea of using (as opposed to the head boundary) the 2048 sector for first partition is entirely arbitrary.

 

What was initially a way to have faster access to rotational disks (with - believe me - very little actual gain in terms of speed and only noticeable with database use) became senselessly standard.

 

BUT when it came to SSD's (or more generally flash based devices) it started to make a lot of sense.

The first (obvious) advantage (at file system level) is that clusters (usually on NTFS 8 sectors or 4096 bytes) become inherently aligned.

The second one (specific for flash and solid state devices) is that the page size (which is the actual unit at which some operations are performed on SSD) is also aligned.

 

The first one is reached with *any* multiple of 8 sectors, though usually powers are used (for slightly different reasons) with an offset of 8, 16, 32, 64, 128, 256, 512, 1024 or 2048 sectors BUT the specific SSD (or flash device) may have a internal "structures", let's call them "page size" and "erase block size" which may (or may not) provide a further slight enhancement, among them, the "page size" is actually be a good idea (while aligning to the "erase block size" makes little sense).

 

These values are (usually but not always) respectively 16 sectors (or 8 kb) and 4096 sectors (256*page size).

 

Some previous related discussion is here:

http://reboot.pro/to...-memory-drives/

 

So, in a nutshell an offset to the first NTFS partition volume of:

16, 32, 64, 128, 256, 512, 1024 or 2048

is "good" and there is NO difference in using the one or the other (if the page size is 8 kb)

 

If the page size is 16 Kb (or 8 Kb), any of:

32, 64, 128, 256, 512, 1024 or 2048

is "good" and there is NO difference in using the one or the other.

 

In practice besides 2048:

64, 128, 256, 512 and 1024

will "cover" page sizes up to 32 Kb in EXACTLY the same manner, and 

128, 256, 512 and 1024 will "cover" page sizes up to 64 Kb in EXACTLY the same manner.

 

Wonko

[alacran]

@ Wonko

 

Good info as allways.

 

alacran