Merging DTrace implicitly means they are fine with both the CDDL and Oracle's patents, and thus that ZFS wouldn't be an issue for them.
Merging DTrace implicitly means they are fine with both the CDDL and Oracle's patents, and thus that ZFS wouldn't be an issue for them.
Also, NTFS already has snapshots via Volume Shadow Copy.
ZFS is great but it’s not going to be a viable replacement as it exists today.
Microsoft strongly recommends developers utilize alternative means to achieve your application s needs. Many scenarios that TxF was developed for can be achieved through simpler and more readily available techniques. Furthermore, TxF may not be available in future versions of Microsoft Windows. For more information, and alternatives to TxF, please see Alternatives to using Transactional NTFS.
https://docs.microsoft.com/en-us/windows/desktop/fileio/abou...
The Sun Storage Appliance used ZFS snapshots for updates, and it worked quite well.
Obviously.
The super annoying thing is when the OS doesn't try to tell you which process(es) keeps it open and doesn't even ship with built in tooling to let you find out on your own.
I think that is the point GP tries to make.
It lets you see which process locked a file, and optionally remove the lock.
PS> $lockedFile="C:\Windows\System32\wshtcpip.dll"
PS> Get-Process | foreach{$processVar = $_;$_.Modules | foreach{if($_.FileName -eq $lockedFile){$processVar.Name + " PID:" + $processVar.id}}} PS C:\> gps |? {$_.Modules.FileName -match "wshtcpip\.dll"} | select name, idOr, imagine every copy of Word you have running is using a different set of binaries.
No, thank you.
I use it in Win 7; I think it works most of the time (not always).
Yeah, it should come with the OS, but that's Windows for you.
NTFS's USN change journal (which is separate from the transaction journal) is also useful as a robust offline alternative to ReadDirectoryChangesW file monitoring. Toy example: https://gist.github.com/pervognsen/bcc610d6a5ae6cbc3b2b4f7aa....
Anyway, the problem I've always had when using non-standard file system metadata like alternate streams or sparse files is that they interoperate poorly in practice. There's lots of code and programs out there that wants to treat everything like a plain old file and hence won't preserve alternate streams or sparseness. From my recollections this is true even for several of Windows's built-in utilities. Same issue if you want to transfer files over a socket or pipe or a non-NTFS storage medium like a FAT-formatted USB drive or a NetApp filer or a source control system. As a result this kind of thing is only really useful when deployed in a bubble; I believe WSL uses alternate streams for Unix permission bits and other Unix-specific file properties. Even though those WSL guest files live in a directory tree on a normal NTFS volume, they strongly caution you against touching them directly outside of WSL, presumably for the aforementioned reasons.
Aside from features, NTFS has some performance issues compared to other modern file systems, notably with lots of smaller files.
- For permissions WSL uses EAs; for capabilities it uses ADS
- I'm not sure if it's really NTFS that is slow with lots of small files or the I/O subsystem in general... I got the impression it's the latter but not sure.
All of these except shrinkable volumes (somewhat) are already part of ZFS, also assuming that you replace "BitLocker integration" with more general "encryption integration"
ZFS and NFSv4 were both designed to be able to serve the entire subset of NTFS features over the network, to interop with Windows computers.
As for ADS: basically xattrs. They can be arbitrarily named and each xattr on ZFS can be up to 16EiB large (same as the primary bin for file content). (As an aside, they aren't fully usable on Linux since Linux itself imposes a 64KiB limit on an xattr's content -- but that's not a ZFS limitation)
Absolutely not! Reparse points are directories that are associated with drivers that extend the capability of the filesystem itself. They can be used to implement symlink-like behavior, but that's only a single use case that scratches the surface of their potential power.
See https://docs.microsoft.com/en-us/windows/desktop/fileio/repa... for more information.
It doesn't sound like it is really an inherent property of the file system, but just controlled by a driver. I don't see why they couldn't be made to work on any other file system, such as FAT or ZFS.
It's available with new kernels (including 5.0) on github as well.
https://github.com/oracle/dtrace-utils
https://github.com/oracle/libdtrace-ctf
https://github.com/ezannoni/dtrace-linux-kernel
We are working on a Fedora version of the kernel patches.
We are also discussing with the BPF team (on netdev) how to provide DTrace functionality integrated with the Linux Kernel.
When you feel slow, it is the abstraction layers and plugable interfaces above it. - and they are API.
Replacing the core won't help the performance. They need to remove some abstraction and break some application.
I think that filesystems like ZFS and Btrfs are simply one step ahead than anything else, not only in features but also in tooling and UX. Send/receive, CoW snapshots, checksumming are all tremendous features that I think would fit fantastically into the Windows workflow, if Microsoft really managed to integrate them well. For instance, I think a ZFS-based Windows update would be able to do away with transactions and rely instead on datasets to snapshot the system, apply an update and rollback everything if something broke, exposing to power users the tools to clearly understand and rollback their systems themselves by hand.
Obviously all of this can be achieved by rewriting everything from scratch as in house, specific platforms, but I just feel that continuing to replicate in NTFS/ReFS features other open and widely supported filesystems have had for almost a decade is just not the best way forward, and it's not really better for anyone.
Does anyone actually use this on Windows these days? I'm guessing the reason so few filesystems support it now is because the gains aren't worth it for the types of files that take up most of the space on filesystems these days, such as video files. You can't compress x264 video with a general-purpose compression algorithm. Storage space is plentiful and cheap, and (general-purpose) compression yields little gains, and the stuff we're storing now is already compressed (images, video, audio, etc.).
Mind that DTrace was ported by Oracle (at least partially) to Oracle Linux first. They haven't done that for ZFS (instead they created bttrfs, before owning Sun)