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

Reply via email to