On Sat, Nov 21, 2015 at 09:56:24AM +0100, Jean-Pierre André wrote: > I have a question on the use of system compression on > Windows 10 : I have two computers running Windows 10. > Both have the same disk size and same partition layout > (64GB for Win10, about 32GB used), but one uses system > compression and the other one does not. There has been > several major updates with this difference of behavior > unchanged. > > Do you know why ?
I'm not sure. I haven't investigated the details of when, exactly, Windows 10 decides to use system compression. But do I believe it's at least partially hardware-based, as you're suggesting. Take a look at this Microsoft blog post: https://blogs.windows.com/windowsexperience/2015/03/16/how-windows-10-achieves-its-compact-footprint/. > So I finally ended up with cacheing the inodes so that > reopening an inode which has been opened recently is > fast. The stat() data are cached, but the runlists are > not. Hmm... I wasn't paying attention to the fact that inodes are cached. Are you saying the issue was that entries in long runlists prior to the read or write took longer to skip over when the runlist was cached as opposed to uncached? Maybe the runlist just needs to be held in a different data structure in memory. > About integrating system compression into ntfs-3g, I > want to try making it a plugin loaded on demand. this > will improve modularity and facilitate maintainance. > For instance an upgrade such as the one you are > announcing could be released independently of ntfs-3g. > In the fuse interface (ntfs-3g.c or lownetfs-3g.c) the > inode would be opened, and if it has a reparse mark, > control would be passed to a handler depending of the > reparse tag, either internal (symlinks and junctions) > or external (system compression). The interface would > be like the fuse one, with the path replaced by a pointer > to inode descriptor. More thoughts needed... Interesting idea. I agree that it would be nice to support new types of reparse points without having them directly tied to the core library/driver. There is quite a bit of code needed to support the system-compressed files and I expect that the majority of users don't need it. I suppose that NTFS-3g would have to provide a plugins directory, a plugin package would drop a .so file into it, and the FUSE driver would dynamically load the available plugins when starting up? I also suppose it would have to be a plugin at the FUSE driver level and not at the library level, since the library interface is more low-level and deals directly with inodes and attributes. I'm wondering about where and what the "hooks" would need to be. In my latest patch I have three "hooks" for system compressed files: one in getattr(), one in open(), and one in read(). But different reparse point handlers will likely need other hooks. I think it's also expected that reparse point handlers will need to override only specific behavior, even within a single FUSE operation, and leave the rest as the default. For example, with system compressed files there is no special behavior needed for alternate data streams and inode metadata such as timestamps, but that may not be true of all reparse points. By the way, Microsoft's software which handles system-compressed files is more than just a reparse point handler. It's actually a filter driver that hides the fact that the feature is implemented using reparse points at all. The reparse point attribute is hidden, and as far as I know there is no way to even tell that a given file is a system-compressed file without using a special ioctl (FSCTL_GET_EXTERNAL_BACKING). But I think that's a complete hack and NTFS-3g doesn't necessarily need to do things the same way... ------------------------------------------------------------------------------ _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel