3 ms·

This is really cool and speaks to the modularity of the Windows file system stack. I love projects that customize Windows (working against its closed-source nat

This is really cool and speaks to the modularity of the Windows file system stack. I love projects that customize Windows (working against its closed-source nature). There’s an OpenZFS port to Windows[0]. I wonder if my hopes of having ZFS on Windows (including the boot drive, because I would love to be able to snapshot and rollback) would actually be possible. [0] https://github.com/openzfsonwindows/openzfs https://github.com/openzfsonwindows/openzfs

infogulch 4y ago
The author has refactored their branch with guidance and promoted their draft pr to open last month. https://github.com/openzfs/zfs/pull/14034 https://github.com/openzfs/zfs/pull/14034
lostmsu 4y ago
But Windows lets you snapshot and rollback via Volume Shadow Copying (System Restore in UI + 3rd party tool Shadow Explorer to browse snapshots).
- EvanAnderson 4y ago
  Having used both VSS and ZFS fairly heavily I much prefer the ZFS experience. It seems more predictable and reliable in fulfilling its function. I am pretty strongly pro-Windows NT. I think there’s a ton of good design and implementation in it. (The parts of NT that came from Win32 are the more irritating parts.) VSS isn’t wholly unreasonable. The design seems pretty well thought-out. I particularly like the VSS providers that can interface with hardware-based snapshot mechanisms and VSS writers to allow software to quiesce IO. It’s all pretty neat, but it seems to fail to take snapshots “mysteriously” pretty often in practice. Since I can’t see the source I don’t have much chance of actually figuring out what’s going wrong either. I also like that VSS is clearly distinct from volume management and the filesystem itself. The layer violation inherent in the design of ZFS seems a bit clunky to me. In use, though, it has done very well for me and I haven’t bumped up against limitations re: volume management and redundancy being tied to the filesystem too much (probably because I’ve always come at it with the expectation that my volumes are pretty much decided at deployment time and migration means starting a fresh zpool and starting over).

infogulch 4y ago

The author has refactored their branch with guidance and promoted their draft pr to open last month. https://github.com/openzfs/zfs/pull/14034 https://github.com/openzfs/zfs/pull/14034

lostmsu 4y ago

But Windows lets you snapshot and rollback via Volume Shadow Copying (System Restore in UI + 3rd party tool Shadow Explorer to browse snapshots).

EvanAnderson 4y ago
Having used both VSS and ZFS fairly heavily I much prefer the ZFS experience. It seems more predictable and reliable in fulfilling its function. I am pretty strongly pro-Windows NT. I think there’s a ton of good design and implementation in it. (The parts of NT that came from Win32 are the more irritating parts.) VSS isn’t wholly unreasonable. The design seems pretty well thought-out. I particularly like the VSS providers that can interface with hardware-based snapshot mechanisms and VSS writers to allow software to quiesce IO. It’s all pretty neat, but it seems to fail to take snapshots “mysteriously” pretty often in practice. Since I can’t see the source I don’t have much chance of actually figuring out what’s going wrong either. I also like that VSS is clearly distinct from volume management and the filesystem itself. The layer violation inherent in the design of ZFS seems a bit clunky to me. In use, though, it has done very well for me and I haven’t bumped up against limitations re: volume management and redundancy being tied to the filesystem too much (probably because I’ve always come at it with the expectation that my volumes are pretty much decided at deployment time and migration means starting a fresh zpool and starting over).