For many reasons, my main desktop computer is Windows. My other computer runs macOS, where I use a different collection of applications. I have lived with these two environments for more than 30 years, and I also started using Linux when the kernel was still in the 2.x generation. I am therefore not particularly loyal to one operating system. I use the platform that does the job.
But throughout those decades, one problem kept returning: storage expansion.
The problem was not simply buying another disk. That part has always been easy. The difficult part was turning several generations of disks, with different capacities and replacement dates, into one large and comprehensible place for my files—without periodically rebuilding everything.
The distinction that matters: a volume is not a filesystem
Storage discussions often mix together three different layers: the physical disks, the logical block device assembled from those disks, and the filesystem placed on top. They are related, but they are not the same thing.
Linux Logical Volume Manager is excellent at the middle layer. I can add a physical volume, extend a volume group and enlarge a logical volume. However, the filesystem above it must still be expanded separately. With ext4, that means growing a filesystem whose internal organisation is based on block groups and whose behaviour depends on features selected when it was created. The Linux kernel documentation explains that ext4 divides a filesystem into block groups; with the usual 4 KiB block size, a group is normally 128 MiB.
To be precise, ext4 does not count how many physical disks LVM has hidden beneath it. My practical problem was not a literal “too many disks” limit. It was that adding disks enlarged the block device, while the same ext4 filesystem—and its original metadata layout, feature flags, resize history and operational risks—had to keep stretching across it. LVM made the container flexible, but it did not make the filesystem irrelevant.
NTFS has the same separation of layers. Microsoft documents that modern NTFS can support very large volumes, with the maximum dependent on the Windows version and allocation-unit size. On current supported Windows versions, the documented ceiling ranges from 16 TB with the default 4 KiB clusters to 8 PB with 2 MiB clusters. Those numbers are impressive, but they do not eliminate the architectural issue. A basic Windows volume normally extends into adjacent unallocated space on the same disk; Microsoft’s volume-extension documentation describes those conditions. Other block-aggregation technologies can span devices, but the result is still one virtual block device supporting one large filesystem.
In other words, the theoretical maximum size was never my only concern. I wanted storage that could evolve safely and conveniently as real disks were added, replaced, reused or removed.
Why ZFS was brilliant—but not the answer for this desktop
ZFS solves many problems magnificently. It combines volume management and the filesystem, uses end-to-end checksums, supports snapshots, scrubs, compression, redundancy and self-healing when redundant good data is available. For a dedicated storage server, it remains one of the most compelling designs ever created.
But its pool topology is a design commitment. Capacity is added through vdevs, and the options for later removing them depend on the layout. Modern OpenZFS can remove some top-level mirrored or non-redundant vdevs by evacuating their allocated data, so the old statement that “ZFS can never remove a device” is no longer universally correct. Nevertheless, the official OpenZFS documentation for zpool remove says that top-level removal is unavailable when the pool contains a top-level RAIDZ or dRAID vdev, and it imposes other conditions such as matching ashift values. That is still a much more topology-dependent life cycle than I wanted.
There was also the operating-system issue. OpenZFS is mature on platforms such as Linux and FreeBSD. Community work exists for Windows, but it is not the ordinary, built-in and broadly supported Windows desktop storage path I wanted to depend upon. In practice, choosing ZFS meant maintaining a third computer as a storage server: another machine, another operating system, another set of updates, another possible failure point and more electricity consumed every hour of the year.
I did not want a storage appliance as a hobby. I wanted expandable storage inside the Windows computer I already operate.
Then an AI mentioned StableBit DrivePool
Last year, while complaining about this problem to ChatGPT or Grok—I honestly do not remember which one—I was told about StableBit DrivePool.
The description initially sounded almost too modest: it combines several physical drives into one virtual drive and stores the contents as standard NTFS or ReFS files. But that simplicity is precisely the important idea.
DrivePool is not pretending that several disks are sectors of one enormous physical disk. Each pool member remains an independently formatted volume. DrivePool chooses a member disk for each pooled file and stores the file in a hidden PoolPart... directory. The software then presents the combined directory tree through one virtual drive letter. In my case, that is P:.
According to the DrivePool manual, adding a drive expands the virtual pool immediately by that drive’s capacity. Existing non-pooled data on the disk is not modified and remains accessible through the disk’s original path; only files placed in the hidden pool directory become part of the pool. Most importantly, pooled files remain ordinary NTFS or ReFS files that can be read for recovery without reconstructing a proprietary block array.
What happens when disks are added or removed
Adding a disk is the easy half. DrivePool makes its capacity available immediately and directs new files according to its placement and balancing rules. The pool can contain disks of different capacities, because files are allocated as whole files rather than striped as fixed-size blocks across every member.
Removal is equally important. DrivePool can evacuate unduplicated pooled files to other members and regenerate protected copies before the member leaves. The pool remains usable during the operation. Naturally, the remaining disks must have enough free capacity; if they do not, removal is aborted. These details are documented in StableBit’s drive-removal procedure.
This is fundamentally different from changing the width of a striped or parity array. There is no requirement that all disks match in size, and no need to rewrite every block merely because the collection contains a new capacity. The unit that moves is an understandable object: a file.
Duplication where it is useful—not everywhere by decree
DrivePool is not RAID, and that is a feature as long as its protection model is understood. By default, a file can exist on one physical disk. If that disk fails, an unduplicated file on it can be lost, although files on the surviving disks remain ordinary readable files.
For data that needs protection from a disk failure, DrivePool provides duplication. I can enable it for the whole pool or choose it by folder. An x2 folder keeps two copies on different physical disks; x3 keeps three. The file-protection documentation explains that existing files can be duplicated in the background and that different folders may use different duplication levels.
This gives me a useful economic choice. Replaceable data does not have to consume two or three times its size. Important documents can receive more protection. It is not the all-or-nothing geometry of a conventional array.
Balancing, placement and performance
A file-level pool must decide where new files go and when existing files should move. DrivePool calls the latter process balancing. Its defaults can work without intervention, but power users can change balancing triggers, schedules and plug-ins. StableBit describes balancing as the transparent redistribution of pooled files among the physical disks, performed with background I/O so normal access can continue.
File-placement rules provide another layer of control. They can restrict folders—or wildcard patterns—to selected disks. This makes it possible, for example, to keep performance-sensitive material on SSDs, confine archives to larger hard disks, or determine which devices may contain a particular category of data. These rules are not merely visual preferences: they influence new writes, background balancing, duplication and drive removal.
Performance also reflects the file-based design. A normal unduplicated file ordinarily resides on one disk, so a single-file transfer does not automatically acquire the aggregate write speed of a striped RAID set. That is an honest trade-off. When a file has duplicate copies, however, DrivePool can use read striping and choose among the available disks according to their load and measured speed. StableBit’s performance documentation describes different strategies for sequential, random and low-concurrency reads.
What DrivePool deliberately does not try to be
DrivePool does not provide ZFS-style end-to-end checksumming and self-healing by itself. It does not turn duplication into historical versions. It does not make a failing disk healthy, and it cannot evacuate data to free space that does not exist. Its virtual drive also depends on the DrivePool software and Windows driver being present, even though the underlying files remain accessible directly.
Those are not hidden defects; they define the product’s scope. DrivePool concentrates on pooling, file placement, duplication and disk life-cycle flexibility. Disk-health monitoring can be supplemented by StableBit Scanner or other tools, while backup and integrity verification remain separate responsibilities.
For my use, that separation is easier to understand and recover than an opaque monolith. If the pooling layer is unavailable, I can still see which files exist on each surviving NTFS disk. If one unduplicated disk fails, the damage is limited to the files on that disk rather than making every surviving member meaningless because a striped set can no longer be assembled.
Why it finally fits my Windows computer
I began by testing DrivePool because the design sounded promising. To my surprise, it was exactly what I had been looking for. This year I committed to it fully, and today my storage appears as drive P: on my main Windows computer.
The value is not that P: is a magically limitless filesystem. Every member disk still has real capacity, every NTFS volume still has limits, and the computer still has finite controller ports, bays, power and cooling. The value is that the pool can expand incrementally without enlarging one underlying filesystem. I can introduce another disk, let new data flow to it, rebalance when useful and later evacuate a member that I want to replace.
That model matches the way storage actually changes over a long period. Disks arrive at different times. Capacities improve. Some folders deserve duplication and others do not. A device eventually becomes old, small or suspect and should leave without forcing a complete redesign.
I have spent decades moving among Windows, macOS and Linux, trying sophisticated storage technologies and repeatedly returning to the same practical frustration. StableBit DrivePool is not the most theoretically ambitious storage system I have used. It is the one whose abstractions most closely match what I wanted my Windows storage to do.
DrivePool is the Windows storage tool I always wanted—and it took me decades to find it.
A painful lesson about Cygwin and NTFS permissions
During the migration, I also discovered an unexpected interaction between Cygwin, NTFS permissions and the DrivePool virtual drive.
Cygwin provides a POSIX-like environment on Windows, but it still has to translate Unix ownership and permission semantics into Windows security identifiers and NTFS access-control lists. DrivePool adds another layer: applications write to the virtual pooled drive, while the actual files are stored on one of the underlying NTFS volumes.
Cygwin operation
│
▼
POSIX-to-Windows permission mapping
│
▼
DrivePool virtual drive
│
▼
PoolPart folder on physical NTFS volume
In my configuration, files moved through Cygwin into the DrivePool virtual drive did not always retain usable Windows ownership and access-control entries. The permissions visible through the pooled drive no longer corresponded properly to the security information on the underlying NTFS files. After enough files had been moved, some of them became inaccessible even to my normal Windows account.
It would not be technically precise to describe this as two independent sets of permissions becoming lost. There is ultimately one Windows security model based on ownership, security identifiers and access-control lists. The problem was the translation and inheritance of that information across Cygwin, DrivePool’s virtual filesystem and the physical NTFS volumes.
To recover the affected files, I had to write a PowerShell script that took ownership of them and reset their NTFS access-control lists. Once the ownership and permissions had been restored to valid Windows entries, the files became accessible again.
This was not evidence that the file contents had been damaged. It was an access-control problem: the data was still present on the pool disks, but Windows could no longer authorise my account to use it correctly.
The practical lesson was clear. For large migrations into DrivePool, I now treat data movement and permission preservation as separate concerns. I test the complete path with a small sample first, inspect the resulting owner and ACLs from Windows, and confirm that the files remain accessible before moving a large directory tree. When permissions do not need to be preserved, it may be safer to copy the contents using native Windows tools and allow the destination to inherit fresh permissions.
Comments
Post a Comment