Hi Szaka, Szabolcs Szakacsits wrote: > Hi, > > Good start for 2008! :-) This year seems to be quite exciting on the NTFS > field! >
So have a very good year ! > On Mon, 14 Jan 2008, Jean-Pierre ANDRE wrote: > > >> This is to announce a candidate release of an extension to ntfs-3g for file >> ownership and protections (ntfs-3g-1.1120SC.1, based on the standard version >> ntfs-3g-1.1120). >> >> Details and dowload are available on >> http://pagesperso-orange.fr/b.andre/security.html >> >> The only change since the latest beta-test version (ntfs-3g-1.1120SB.5, Dec >> 14th) is the use of an LRU cache to get the inode numbers >> > > Cool, I'll check it out. > > Btw, could you please move the /NTFS-3G directory to a hidden /.NTFS-3G? > I think we agreed on this sometime ago when we discussed that OS X also > needs to store some files in /.NTFS-3G. > > Ok, I was not aware of this request. I will also set up a mount option to designate any location on a previously mounted fs. >> and the deactivation of cacheing of file attributes by FUSE. This >> decreases significantly the CPU usage by ntfs-3g (the impact on CPU usage >> by fuse is unknown) and fixes a hard link problem caused by the >> unawareness of hard linked files by FUSE. >> > > Hmmm, if I remember correctly then disabling FUSE attribute caching doesn't > solve all the problems (I'll check for the known issues). To avoid those > problems Miklos suggested the usage of the low-level FUSE interface and > this is indeed planned for a while for much better performance and less > code. > That remains possible. The fuse test program still fails on the number of links for a directory, but this is due to ntfs-3g not counting the number of subdirectories. >> I have benchmarked this version on recompiling ntfs-3g from the tarball >> (gzip, tar, configure, make), doing about 4000 file or directory openings >> (among which 900 were file creations). The relative CPU usage by successive >> versions of ntfs-3g are as follows : >> >> standard ntfs-3g no security 100% (reference) >> ntfs-3g plus security no caching 130% >> ntfs-3g plus security cached 108% >> same plus inode number cacheing 45% >> same without fuse attribute cacheing 47% >> >> An equivalent ratio is met on the number of physical reads requested by >> ntfs-3g (242661, instead of 534743 for the reference version), but the real >> impact on data access times is probably much less because of the cacheing >> done by the kernel. Moreover the cacheing has no effect on writings, so there >> should be no impact on disk throughput when copying large files. >> > > Thank you for doing this! > > I have also made some benchmarks. User mapping wasn't used, so I could > compare the speed improvements itself better with the standard version. > > Bonnie++ result: > File creation: 10% improvement > File stat: 50% decrease <-- disabled fuse cache, quite probably > You can just remove the FUSE timeout option to confirm your diagnosis. > File removal: 20% improvement > > Concurrent write (tiotest): 20% improvement > > Unpacking kernel (23,000+ files): 50% improvement > Running 'find' on kernel: 20% improvement > Removing kernel tree: 40% improvement > > Quite good results! Moving to the low-level interface should also improve > at least further 20-50% in general on the performance. > > Btw, I think we don't need path_normalize(). FUSE should do it already. > Afair, paths must always start with '/' and the trailing slashes seems to > be always removed as well. > Not so simple. "Internal" files names ($Secure, etc.) are generally designated without a leading '/', and building parent directory names frequently leaves a trailing '/'. So normalizing both ends appears safer (and easier) than finding all occurrences of these situations. Regards Jean-Pierre ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
