I recently began experimenting with Diskless Angel on Asus EEE mini-laptops, as I believe it could provide a solution to a couple of areas that cause concern to EEE users.
The EEE pc is a wonderful machine, but many users are concerned because it uses flash memory "disks" which degrade with every write. The built in flash SSD is reasonably fast and therefore recommended for OS install, but it is soldered to the motherboard, so if errors occur over time, it cannot be replaced. A better solution in this case would be to use the second SSD provided; this can be removed and replaced (and has a greater capacity than the soldered-in SSD), but as EEE users have found out, it is very slow and truly disappointing if used to install and run XP.
I initially tried using post-boot ramdisk, and moving temporary files and other write intensive system files to this, but I still found that there are quite a few system files being written to that do not allow relocation, for example the registry files and event logs, and they still cause large performance issues.
Then I discovered Diskless Angel. It seemed to be ideal for what I wanted to do. Using Diskless Angel, you could boot and load a partition from the slow SSD into RAM. All at once, you remove the constant wearing of the flash SSD, and get RAM speed hard drive access, which is faster by a magnitude over the SSD.
I experimented with using reduced size XP installs, using nlite, but this seemed to cause other issues on the EEE as I tried to install other applications that depended on services removed by nlite, so I eventually decided to use a full XP installation, and possibly reduce it at a later stage.
The system I am using is an ASUS EEE PC 901, with 2 GB of RAM, and 20 GB of storage (4 GB + 16 GB SSDs). There is a normal full XP install on the C: partition. The C: partition is the 4 GB soldered-in SSD, and is identified by the system as hard drive 0. This partition is not used for the Diskless Angel configuration, other than some boot loader components (grub4dos).
The D partition is specifically configured for Diskless Angel. It is 1.5 GB in size, and contains a separate bootable full install of XP. On this is installed the trial version of Diskless Angel. It is fully configured, with the virtual SCSI device driver installed.
I have managed to successfully boot using Diskless Angel, which loads the entire 1.5 GB to RAM and identifies it as the E: drive. This runs very effectively, and shows the promise of what this solution could provide, but I had to work around some problems found to get it to what is a partially usable state.
Firstly, the EEE 901 uses the Intel Atom processor, which uses Hyperthreading technology. When I installed XP on the D: partition, everything was fine and it boots directly from this partition without any problems. However, when booting on the ramdisk (which is an exact image of the D: partition), after getting the initial Windows XP splash screen, it went dark for about 10 seconds, and a BSOD appeared every time. It took me several days of experimenting before I found that disabling Hyperthreading in the BIOS allows it to boot up all the way.
The second issue is that once booted on the ramdisk, everything works fine for a few minutes, but then an error appears, indicating a serious error with ntdll.dll. Corresponding with this appears to be the death of one of the svchost.exe processes, and a large number of windows services stopping. These services include the DHCP client, Wireless Zero Configuration service and Cryptography service, amongst many others, which kills wireless networking at the same time. Again, this only happens when booting on the ramdisk, using the original source D: partition, everything works fine. I restart the necessary services manually to re-enable wireless access which allows me to continue, but obviously, the real cause needs to be corrected.
The final issue I have is with Volume Shadow Copy. The problem with using a ramdisk is volatility; when you shut down, all the modifications, new files created, and even file deletions are lost, and you end up reverting back to the source image (or source partition in this case). The solution I had envisaged was to use volume shadow copy. This could be used to copy all the changes, including systems files not normally accessible for copying during run time (e.g. the registry), back to the source partition. This could be set up to run manually, on a schedule, or using shutdown or logoff scripts, by way of the vshadow command line tool.
The problem is though, that you cannot successfully make a shadow copy of the Diskless Angel ramdisk. An error appears during the process referring to an "Unexpected Provider Error" after which it exits. Again, it does work for the other partitions. In fact, when booted to, and running off the ramdisk, you can perform shadow copies of the other partitions. It appears that the virtual SCSI device is, in it's current form, not compatible with the shadow copy service on XP. I can't see users rebooting to the source partition every time they want to install an application, or to ensure that other registry changes then need to stay permanent are saved, so I believe it would be essential to correct this, and ensure shadow copy works for the ramdisk before it would be an acceptable solution.
If these issues were resolved however, Diskless Angel would remove a couple of the disadvantages of the EEE pc, and significantly improve the performance and usability of this platform. Even with the current limitations I have outlined, I can see the very strong potential it has, and can see a lot of interest in it from the EEE community if these problems can be addressed.
Links: Diskless Angel
