2008/7/25 Jean-Pierre ANDRE <[EMAIL PROTECTED]>:
> That is a consequence of using the high-level fuse interface,
> for any action on a file you have to get its context from the
> file name.

There is the fh field of the fuse_file_info struct for saving context
(or rather, a pointer to the context).


> Do you mean you keep the inode open ? You may have problems with
> concurrent access to the file.

That's one of the things that's been at the back of my mind - I've
improved performance but have I compromised data integrity?


> You could also get into problems
> after a power shortage.

The approach taken only reduces the likelihood, it won't, of course,
remove the problem.

I'm currently pondering whether I can get the best of both worlds by
keeping the inodes around but syncing them to disk if they're dirty.


> I would rather suggest you cache inode numbers. I got significant
> improvements this way (halved the cpu usage). Have a try with
>
> http://pagesperso-orange.fr/b.andre/security.html

Cheers. Will have a look.


> I still admit the top four functions which make the most use
> of the cpu are related to finding an inode from path.

As mentioned, I think you can just get the pointer previously stored
in the fuse_file_info struct.

Given that I no longer needed the path to find the inode, I also tried
removing the calls to get_path in fuse_lib_read and fuse_lib_write.
The performance gain was minimal (approx 4%) since I was saving 25% of
a process that was now only taking 17% of the CPU time.


Thanks for the useful reply.

-- 
Sven

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel

Reply via email to