The M2 (Milestone 2) beta build of StableBit DrivePool is now available.
The developers state that M2 is mostly a plumbing build and features a lot of new stuff under the hood but not much changes in the UI department. Nevertheless, there are many interesting things to talk about:
Long path names
Windows path names are normally limited to 260 characters, give or take a few. But path names in DrivePool M1 builds were limited to much less (somewhere around 180 characters). This was because the original design did not use extended paths for its underlying file access.
Windows has the concept of extended Unicode paths that are limited to 32k+ characters, but only if the program is written to take advantage of it. DrivePool M1 was not, and so some people ran into this limitation. Later M1 builds attempted to alleviate the issue by utilizing path collapsing to short 8.3 file names (the same approach that Windows Explorer uses from what I understand). This worked, but it was still limiting.
DrivePool M2 completely revamps its use of the Win32 API to use extended paths everywhere. This means that any program that reads or writes on the pool will be able to take advantage of the 32k+ path limit. Programs that are not written to take advantage of extended path names will be limited to 260 characters, this is simply a Windows limitation and we can’t do anything about it.
Native volume detection
DrivePool M1 relied on the Windows Home Server 2011 to tell it when disks are plugged in and removed. M2 was designed to work with Windows directly using the same API as Disk management. This means that DrivePool will get notified when disks are plugged in, volumes are formatted, mounted and unmounted. DrivePool M2 also monitors the root directories of all the volumes for any changes that might affect the pool parts.
All in all, this makes for a much more robust pool part detection system. Also, this paves the way for DrivePool to work outside of the Windows Homes Server ecosystem.
Mount points are irrelevant
DrivePool M1 relied on drive letters to access each pool part. This has the disadvantage of limiting the total number of drives that can be made part of the pool. Not any more. M2 does not use mount points at all. You can un-mount, re-mount any pool part without affecting DrivePool. This means that it’s really up to you to decide if you want to use drive letters or not.
Adding raw disks to the pool / Hidden pool disks
The default behavior of the Windows Home Server 2011 is still to assign drive letters to new disks. However, DrivePool now has the ability to add uninitialized or un-partitioned disks to the pool. In such a case, DrivePool will initialize the disk as a GPT disk and format it with NTFS. If you let DrivePool format your new disk, you will be presented with an option whether to assign a drive letter to your new disk or not.
Assigning a drive letter will let you create non-pooled folders on a pooled disk and thus share it with pooled and non-pooled files. A hidden disk will not consume a drive letter, leaving more drive letters available for use by other disks.
Error condition detection and recovery
I suppose this is the heart of the M2 build, if anything is. DrivePool M2 now has facilities to deal with missing disks, foreign pooled disks, I/O errors and duplication errors.
Because of the scope of this topic, I will make a separate post describing how this all works. In summary, DrivePool M2 works hard to make sure that your files on the pool stay safe, and that duplicated files are not lost.
Read / write fault tolerance for duplicated folders
This goes together with the above feature. DrivePool M2 ensures that under most circumstances a read or write operation on a file in a duplicated share does not error out. In other words, if you’re saving MyPasswords.kdb onto a duplicated share, and one of the drives experiences a write error, DrivePool will make sure that the write succeeds and that the file being saved is not corrupt.
ETW based logging
Every I/O operation on the pool is now logged in the kernel in all its glorious detail. The logging is done using the high performance Event Tracing for Windows infrastructure. Logs are written in a compact binary format to a circular log file that automatically wraps around deleting the old log entries with new ones.
While this doesn’t mean much for the user, it is immensely useful for troubleshooting any I/O problems remotely.
Other miscellaneous fixes / improvements
- Asynchronous service start-up – The M1 service was on a 30 second timeout, and so on systems that were slow to start up it would sometimes time out. The new M2 service starts instantly.
- WHS notifications – Notifications are now raised when an error condition is detected on the pool (more on this later).
- Some bug fixes in the driver with alternate streams, directory opens, access violations and more…