Digg this topic Add to my del.icio.us Submit to SlashDot  
Reply to this topicStart new topic
> ImDisk as Network Boot Device or Disk Driver, Virtual Disk Drive versus Virtual Volume
Andy Tim
post Aug 1 2007, 10:08 PM
Post #1


Newbie
*

Group: Members
Posts: 8
Joined: 1-August 07
Member No.: 9,903


Canada


Hello all,

Thanks for the great product, Olof.

We see various technologies today like Citrix, Ardence, Softricity, Neoware produce, using filesystem filters and lower-level disk virtualization drivers. The idea of various disk and filesystem levels with transparency for the end-application probably should have been implemented a long, long time ago. It has been possible with Linux for some time.

We notice two technologies released with Windows XP Embedded: Sector Disk System Deployment Image (SDI) and Enhanced Write Filter (EWF). SDIs are virtual disk drives, EWFs are an implementation of volume (filesystem) layers. There is another fellow from MS who comes in useful for booting Windows, the Windows Server 2003 RamDisk. With Vista we get .WIM files.

I have seen the postings at http://www.boot-land.net/forums/RAMdisk-an...vers-t1507.html and see that some of the links there (like the VDK link) mention whether their drivers are disk drivers or filesystem drivers.

So Windows XP in /MININT mode is not quite as useful as in regular mode. But how can we load a "real" XP to RamDisk or perhaps over the network? What we need is what Ardence (now Citrix) and I believe NeoWare have: a disk driver with low-level network functions. What would be ideal to me is if ImDisk were wrapped by or changed to a disk driver instead of a volume driver. Additionally, low-level network capabilities could be added so it could provide the virtual disk with a network-backed file store. Even better than that would be if the networking could switch between a low-level mode and a higher-level mode. I realize that this post is all over the place so let me paint a picture:

- A PC PXE-boots a very small HDD image.
- This image has NTLDR and starts loading Windows
- Once we start accessing files with the virtual disk driver (some super ImDisk version) read-write operations go over the ethernet cable with a tiny IP stack to a file-store
- Windows XP loads up, loads up high-level networking stacks
- The virtual disk driver switches to use the high-level networking
- A user disconnects the original PXE-boot media cable
- The virtual disk driver sees that the backing file-store resource is available wirelessly
- The PC is empty: no optical disk drive, no hard disk drive, no USB stick, no network cables
- The PC is running full-blown Windows XP

Maybe the virtual disk driver could optionally reserve some RAM to allow file operations to take place while the file-backing was unavailable. Maybe the driver could use registry parameters to try other fallback file-stores on alternate servers (as long as the image was the same!).

If a filesystem delta layer was added to this to allow changes to be saved separately from a base image, you might as well eat your hat with glee.

While I've probably only succeeded in confusing a reader, I think that a good starting point would be to offer ImDisk as a disk driver, rather than as a volume driver. Or both! How hard would it be to convert it or wrap it? I know that the MS RamDisk sample might be useful for this. While driver programming has always been my locked door, I would certainly contribute in any way I could to this effort.

What think the excellent community here?
Go to the top of the page
 
+Quote Post
...Tim...
post Aug 1 2007, 10:54 PM
Post #2


Member
**

Group: Members
Posts: 11
Joined: 30-April 07
Member No.: 6,392


Germany


Hi Andy,

you may perhaps have a look at diskless angel. It's a ramdisk driver that takes over a memdisk from GRUB4DOS on the fly during the boot of Windows.

Apart from that you should keep in mind that it will almost certainly be disastrous to switch the underlying device of a running filesystem. On the other side above the filesystem you will have to deal with handles to files that are open at the time switching.

Tim
Go to the top of the page
 
+Quote Post
jaclaz
post Aug 2 2007, 03:37 PM
Post #3


Finder
***

Group: Advanced user
Posts: 1,581
Joined: 14-July 06
Member No.: 2


Italy


@Andy
This has already been a bit discussed, but I guess that it isn't that easy to make the needed changes:
http://www.911cd.net/forums//index.php?sho...c=19960&hl=
though actually the RAMDISK driver appears to be NOT a "real" "Miniport" or "disk" driver, but rather a "partition" driver, just like IMDISK already is.

Happy you joined us (IMG:http://www.boot-land.net/forums/style_emoticons/default/smile.gif) , maybe you can review the linked pages and more generally what has already been said on the topic (search on both boot-land and 911CD for "filedisk" and you'll find a number of threads more or less related to this problem) and suggest some new opinions, points of view and/or useful experience.

jaclaz
Go to the top of the page
 
+Quote Post
Andy Tim
post Aug 3 2007, 09:31 PM
Post #4


Newbie
*

Group: Members
Posts: 8
Joined: 1-August 07
Member No.: 9,903


Canada


Thanks for the views, community, and the repluys gies.

Pondering the situation more, it really seems that the only answer for a full-blown XP installation running on an empty PC using a wireless network-accessed disk store is a product even more advanced than Ardence and NeoWare offer.

It's no problem to PXE boot a PC and MEMDISK a hard disk image (remember it's a full HDD, not just a partition!) to get XP started... You could have just the NTLDR, BOOT.INI, NTDETECT.COM, Windows\System32\Config\SYSTEM (and other registry hives), Windows\System32\Drivers\*.sys files on the image's partition. Heck, you can even fit a lot of this stuff on a large floppy image and MEMDISK that!

Anyway, the .SYS files you would need to include would have to be those services which are loaded at boot time; perhaps not all the .SYS files as some might be loaded later on in the boot process after the hump where XP switches to using the XP disk driver instead of BIOS routines to access more files. I believe this is where the hated Blue Screen of Death for UNMOUNTABLE_BOOT_VOLUME occurs.

I guess if your XP disk driver had the low-level network routines that I mentioned earlier (maybe even inherited from the PXE boot process?!), and it was associated as a GenDisk in the registry, you could avoid the Blue Screen.

I love Linux' pivot_root. Another alternative is to load a small (but not setup-mode or /MININT) XP on a ramdisk, establish networking, then (either through a filesystem filter or JUNCTION points or some other clever business) continue the boot process and load the later services, Winlogon.exe, etc. The disadvantage to this is that you still lose RAM to the ramdisk, however small it is. If only: XP pivot_root.

Well that's something to think about, but now I think that I should separate that subject matter from a request for ImDisk. I would really like to see ImDisk as a disk driver, providing something akin to an IDE, SCSI, SDI or MS Ramdisk Controller. Then ImDisk could be used to load instances of whole physical drives still using the great logic that it currently uses to provide volumes. I would like to see all drive-letter business removed from this kind of ImDisk, so that Disk Management and Volume Manager's MOUNTVOL.EXE would take care of them. This kind of ImDisk should provide \\?\Device\HarddiskXXX instead of the current ImDiskXXX devices.

The file offset feature is so fantastic! I used to use FileDisk to mount a volume, then do whatever, unmount it, DD with a seek offset into a full HDD image. All for use in QEmu. Was that ever annoying and somewhat tricky stuff to figure out at the beginning! I don't know how useful the file offset would be if providing a whole disk, but I'm sure someone would find that great logic handy. Thanks again, Olof.

A huge advantage to providing a (virtual) physical disk would be in using tools like PartitionMagic and Ghost and friends. Imagine PartitionMagicking a drive provided by DEVIO on a live FreeBSD disc on some whacked machine! I used to try to do some tricky routing into a QEmu, where the VM would run PartitionMagic and have access to the far-away HDD, but I never figured it out! I think ImDisk as an alternative to Microsoft SDI would mean power to our community!

About SDI: When looking in Device Manager, viewing devices by connection, we see Storage Device Image Device as a branch containing the SDI disks. If you look at the driver properties for the branch, that's where we see SDI.SYS. If we look at the SDIDisk on that branch, we see DISK.SYS and PARTMGR.SYS. This is an exactly identical structure to an IDE channel with a disk, but IDE channels have the STORPROP.DLL as a driver, too, or at least mine does. If we view hidden devices, we see a Volume Manager branch, whose driver is FTDISK.SYS. All of our volumes (partitions) live as leaves on that branch. Their drivers are all VOLSNAP.SYS. I think that following this structure is how ImDisk could really shine.

Just my opinion, I'm going to be enjoying ImDisk as it is quite thoroughly anyway!
Go to the top of the page
 
+Quote Post
Andy Tim
post Aug 5 2007, 05:46 PM
Post #5


Newbie
*

Group: Members
Posts: 8
Joined: 1-August 07
Member No.: 9,903


Canada


Anyone interested in some of the network booting XP subject matter I mentioned might look at http://www.boot-land.net/forums/Network-Bo...g-XP-t2798.html, instead of the ImDisk subforum.
Go to the top of the page
 
+Quote Post

Fast ReplyReply to this topicStart new topic

Members Who Viewed Topic Today ()

 

RSS Lo-Fi Version Time is now: 27th February 2008 - 05:07 PM

MKPortal ©2003-2006 mkportal.it