Fwd: requesting feedback on a few optimizations for fuse

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi

Hello,

I am developing a fuse file system and would love to see some optimizations made to fuse.  Let me describe those below and would love to know your thoughts on these.  Please let me know if you need additional information.

  1. Currently, it looks like there are too many getxattr/removexattr calls being made on files which does not have any extended attributes, those are coming from many unix commands like ls etc..  I am wondering if we could add a new field to struct fuse_entry_param or something equivalent to denote the file does not have any extended attributes and such information can be cached by the kernel along with rest of the file attributes.  So after normal getattr()/lookup() call, the kernel can avoid subsequent calls to getxattr()/removexattr() if the file does not have any extended attributes.
  2. Currently, fuse has an option to invalidate pages of a file in kernel page cache as part of open(2) - keep_cache.  I am wondering if another option can be provided to do the same (invalidate pages in page cache) as part of last close(2) on the file.  Then we can avoid an explicit notify_inval calls from release callback, in situations where pages in kernel page cache are not desired when file is not open.
  3. Would it be possible to provide a mount option or file open mode, which when set, pages of the file are not cached in kernel page cache, unless the file is memory mapped?  The current mount option for direct I/O breaks mmap(2).  It would be good to have another option with which mmap() can be supported, but at the same time page cache is bypassed unless the file is mmapped.

I would really appreciate your feedback on these.

Regards,
Joseph Jobi
File System Architect


------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Nikolaus Rath
On Nov 22 2016, Joseph Jobi <jobi-d/eNp5y7OX9Wk0Htik3J/[hidden email]> wrote:

> Hello,
>
> I am developing a fuse file system and would love to see some optimizations
> made to fuse.  Let me describe those below and would love to know your
> thoughts on these.  Please let me know if you need additional information.
>
>
>    1. Currently, it looks like there are too many getxattr/removexattr
>    calls being made on files which does not have any extended attributes,
>    those are coming from many unix commands like ls etc..  I am wondering
>    if we could add a new field to struct fuse_entry_param or something
>    equivalent to denote the file does not have any extended attributes and
>    such information can be cached by the kernel along with rest of the file
>    attributes.  So after normal getattr()/lookup() call, the kernel can avoid
>    subsequent calls to getxattr()/removexattr() if the file does not have any
>    extended attributes.
>    2. Currently, fuse has an option to invalidate pages of a file in kernel
>    page cache as part of open(2) - keep_cache.  I am wondering if another
>    option can be provided to do the same (invalidate pages in page cache) as
>    part of last close(2) on the file.  Then we can avoid an explicit
>    notify_inval calls from release callback, in situations where pages in
>    kernel page cache are not desired when file is not open.
>    3. Would it be possible to provide a mount option or file open mode,
>    which when set, pages of the file are not cached in kernel page cache,
>    unless the file is memory mapped?  The current mount option for direct I/O
>    breaks mmap(2).  It would be good to have another option with which mmap()
>    can be supported, but at the same time page cache is bypassed unless the
>    file is mmapped.
>
> I would really appreciate your feedback on these.


I don't see anything obviously wrong with any of those
suggestions. However, it would be useful if you could provide some
information about how much performance improvements you actually
expect. Are you sure that e.g. the xattr calls are really slowing you
down? Have you measured it?

For your second suggestion, in which situation would you not know if you
want to keep the cache on open()?

Also all of your suggestions will need to be implemented mainly in the
kernel rather than libfuse. So you will probably get more useful
feedback on the linux-kernel or linux-fsdevel mailing lists.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Stef Bon-2
In reply to this post by Joseph Jobi
2016-11-23 3:24 GMT+01:00 Joseph Jobi <[hidden email]>:

>
> Hello,
>
>
> Currently, it looks like there are too many getxattr/removexattr calls being
> made on files which does not have any extended attributes, those are coming
> from many unix commands like ls etc..  I am wondering if we could add a new
> field to struct fuse_entry_param or something equivalent to denote the file
> does not have any extended attributes and such information can be cached by
> the kernel along with rest of the file attributes.  So after normal
> getattr()/lookup() call, the kernel can avoid subsequent calls to
> getxattr()/removexattr() if the file does not have any extended attributes.

You want per file tuning?

A command like ls will try to determine the access using acl
(system.posix_acl_access/system.posix_acl_default).
Well first step is to disable getxattr calls by returing ENOSYS.

And there have recently been work done on acl. I guess there is at
initialization
an option to disable acl's at all.
But these are global options and will work for all inodes.

Stef

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi
I don't want to disable extended attributes completely since some applications are using those.
But concerned seeing the large number of getxattr()/removexattr() being made to userspace fuse library when the kernel can simply avoid those calls when a file does not have extended attributes.

On Mon, Nov 28, 2016 at 9:08 AM, Stef Bon <[hidden email]> wrote:
2016-11-23 3:24 GMT+01:00 Joseph Jobi <[hidden email]>:
>
> Hello,
>
>
> Currently, it looks like there are too many getxattr/removexattr calls being
> made on files which does not have any extended attributes, those are coming
> from many unix commands like ls etc..  I am wondering if we could add a new
> field to struct fuse_entry_param or something equivalent to denote the file
> does not have any extended attributes and such information can be cached by
> the kernel along with rest of the file attributes.  So after normal
> getattr()/lookup() call, the kernel can avoid subsequent calls to
> getxattr()/removexattr() if the file does not have any extended attributes.

You want per file tuning?

A command like ls will try to determine the access using acl
(system.posix_acl_access/system.posix_acl_default).
Well first step is to disable getxattr calls by returing ENOSYS.

And there have recently been work done on acl. I guess there is at
initialization
an option to disable acl's at all.
But these are global options and will work for all inodes.

Stef


------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi
> I don't see anything obviously wrong with any of those
> suggestions. However, it would be useful if you could provide some
> information about how much performance improvements you actually
> expect. Are you sure that e.g. the xattr calls are really slowing you
> down? Have you measured it?

When I run "ls -l" in a directory with 10000 files in it, fuse library is getting 10000 lookup calls and 20000 getxattr calls.
As these files don't have any extended attributes, getxattr calls are returning immediately, but only after looking up the corresponding inode and taking a shared lock on it.
For the time being, I can avoid looking up the inode if a file system does not have any extended attributes, but that optimization does not work if some files have extended attributes.
Also the cost of roundtrip getxattr call from kernel to fuse library cannot be avoided that way.  Here are the count of various fuse library calls made when "ls -l" is invoked on a directory with 10000 files in it.
Overall, I would say the performance gain would be 10-20% if these unnecessary getxattr calls are skipped.

                 LOOKUP:      10000 
                GETATTR:          2  
                OPENDIR:          1   
                READDIR:         80 
             RELEASEDIR:          1   
               GETXATTR:      20000 

> For your second suggestion, in which situation would you not know if you
want to keep the cache on open()?

It is ok for the kernel to cache pages while the file is open, but should be invalidated at the time of close since you never know whether there will be another open on the same file again soon.
So if the file is not opened again, the pages may hang around in the page cache longer than desired.
I have implemented a snapshot file system and data is shared in snapshots, if same data is read from different snapshots all such data may create duplicate instances of same data in kernel page cache,
as files sharing data in snapshots are using different file handles and kernel page cache today does not have any means to detect that.
So rather than waiting for the next open to invalidate the pages, I would like to have the pages invalidated in kernel page cache at the time of close.
Also I have my own page cache maintained by the fuse file system and don't want pages to be cached in two places. 
I could not find a way to skip kernel page cache altogether without breaking mmap(2), so chose to invalidate page cache on last close on the file.
If fuse had an option to do that, I could have used that instead of making an explicit notify_inval call.



On Mon, Nov 28, 2016 at 9:37 AM, Joseph Jobi <[hidden email]> wrote:
I don't want to disable extended attributes completely since some applications are using those.
But concerned seeing the large number of getxattr()/removexattr() being made to userspace fuse library when the kernel can simply avoid those calls when a file does not have extended attributes.

On Mon, Nov 28, 2016 at 9:08 AM, Stef Bon <[hidden email]> wrote:
2016-11-23 3:24 GMT+01:00 Joseph Jobi <[hidden email]>:
>
> Hello,
>
>
> Currently, it looks like there are too many getxattr/removexattr calls being
> made on files which does not have any extended attributes, those are coming
> from many unix commands like ls etc..  I am wondering if we could add a new
> field to struct fuse_entry_param or something equivalent to denote the file
> does not have any extended attributes and such information can be cached by
> the kernel along with rest of the file attributes.  So after normal
> getattr()/lookup() call, the kernel can avoid subsequent calls to
> getxattr()/removexattr() if the file does not have any extended attributes.

You want per file tuning?

A command like ls will try to determine the access using acl
(system.posix_acl_access/system.posix_acl_default).
Well first step is to disable getxattr calls by returing ENOSYS.

And there have recently been work done on acl. I guess there is at
initialization
an option to disable acl's at all.
But these are global options and will work for all inodes.

Stef



------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Stef Bon-2
In reply to this post by Joseph Jobi
Hi,

removexattr? Normally only getxattr will appear.
As I said earlier I think there is an option (or in the make) that
fuse will not look for the extended attributes system.posix_acl_access
and system.posix_acl_default.
(there are two, that's why you get for every new file 2 getxattr calls).

This option will prevent the fuse kernel module to not send any
queries to userspace for ACL's in xattr.

Stef

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi
I have seen unnecessary removexattr() calls in large numbers coming to fuse when the file does not have any extended attributes, but have not tracked down what exactly triggering those calls.

About the new ACL option you mentioned, is that a file system wide option or something we can do on a per file basis?

On Mon, Nov 28, 2016 at 12:50 PM, Stef Bon <[hidden email]> wrote:
Hi,

removexattr? Normally only getxattr will appear.
As I said earlier I think there is an option (or in the make) that
fuse will not look for the extended attributes system.posix_acl_access
and system.posix_acl_default.
(there are two, that's why you get for every new file 2 getxattr calls).

This option will prevent the fuse kernel module to not send any
queries to userspace for ACL's in xattr.

Stef


------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Nikolaus Rath
In reply to this post by Joseph Jobi
On Nov 28 2016, Joseph Jobi <jobi-d/eNp5y7OX9Wk0Htik3J/[hidden email]> wrote:
>> For your second suggestion, in which situation would you not know if you
>> want to keep the cache on open()?
>
> It is ok for the kernel to cache pages while the file is open, but should
> be invalidated at the time of close since you never know whether there will
> be another open on the same file again soon.

Isn't this exactly what FUSE does if you set keep_cache to zero?
Contents are cached while the file is open, but discarded when all fds
have been closed.

> So if the file is not opened again, the pages may hang around in the page
> cache longer than desired.

Why do you care about that? If the kernel runs low on memory, it'll evict
them without you having to do anything.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi
In reply to this post by Joseph Jobi
> Isn't this exactly what FUSE does if you set keep_cache to zero?
> Contents are cached while the file is open, but discarded when all fds
> have been closed.

Currently, FUSE invalidates pages on open, not on close.  So if a file is not opened anymore, its pages may be cached in kernel page cache for longer periods.

>> So if the file is not opened again, the pages may hang around in the page
>> cache longer than desired.

> Why do you care about that? If the kernel runs low on memory, it'll evict
>  them without you having to do anything.

I am implementing a snapshot/overlay file system and data is shared between files in the snapshots.
The files in snapshots would have different file handles (snapshot number + inode number) and kernel cannot detect duplicate data and all those will flood up the page cache.
So I need to keep the impact on the kernel page cache to the very minimum by invalidating the kernel page cache as quickly as possible.
Otherwise, there will be too much pressure on the kernel page cache and system memory, and useful data from the page cache may be thrown out and swapping may kick in.

That is the reason I suggested one more option, where FUSE provides an option to bypass the kernel page cache for data read which are not memory mapped.
Current direct mount option (or open mode) cannot be used for that purpose since mmap(2) will not work when that is implemented.

On Mon, Nov 28, 2016 at 1:51 PM, Joseph Jobi <[hidden email]> wrote:
I have seen unnecessary removexattr() calls in large numbers coming to fuse when the file does not have any extended attributes, but have not tracked down what exactly triggering those calls.

About the new ACL option you mentioned, is that a file system wide option or something we can do on a per file basis?

On Mon, Nov 28, 2016 at 12:50 PM, Stef Bon <[hidden email]> wrote:
Hi,

removexattr? Normally only getxattr will appear.
As I said earlier I think there is an option (or in the make) that
fuse will not look for the extended attributes system.posix_acl_access
and system.posix_acl_default.
(there are two, that's why you get for every new file 2 getxattr calls).

This option will prevent the fuse kernel module to not send any
queries to userspace for ACL's in xattr.

Stef



------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Nikolaus Rath
On Nov 28 2016, Joseph Jobi <jobi-d/eNp5y7OX9Wk0Htik3J/[hidden email]> wrote:
> That is the reason I suggested one more option, where FUSE provides an
> option to bypass the kernel page cache for data read which are not memory
> mapped.

I see. But unless you'll be providing code implementing the option as
well, this is probably going to remain a suggestion for the foreseeable
future.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Miklos Szeredi
On Tue, Nov 29, 2016 at 6:04 AM, Nikolaus Rath <[hidden email]> wrote:
> On Nov 28 2016, Joseph Jobi <jobi-d/eNp5y7OX9Wk0Htik3J/[hidden email]> wrote:
>> That is the reason I suggested one more option, where FUSE provides an
>> option to bypass the kernel page cache for data read which are not memory
>> mapped.
>
> I see. But unless you'll be providing code implementing the option as
> well, this is probably going to remain a suggestion for the foreseeable
> future.

Or add an bug to the issue tracker at the fuse project.

Thanks,
Miklos

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Stef Bon-2
In reply to this post by Joseph Jobi
2016-11-28 22:51 GMT + 01: 00 Joseph Jobi <[hidden email]>:
> I have seen Unnecessary removexattr () calls in large numbers coming to fuse
> when the file does not have any extended attributes, but have not tracked
> down what exactly triggering Those calls.

That was unexpected. Fuse does not send removexattr to userspace When
a extended attribute is not found. That would be usefull double:
you do not have to delete a xattr if it is not there. What do you
reply to the VFS?

>
> About the new ACL option you Mentioned, Is that a file system wide option or
> something we can do on a per file basis?

I'm afraid I do not understand you, or you me ...
Disabling the posix acl's on a filesystem will preventinfo getxattr
calls for the system.posix_acl_access xattr, but you still willhave
extended attributes, to implement your own extended attributes on your
filesystem. This will get you get rid of most of the calls getxattr
you Mentioned in the example. You can test your FS and log the name of
the xattr.

Better is to file a bug / suggestion on the issue tracker as mentioned.

Stef

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi
How does Fuse know not to send removexattr to userspace when an extended attribute is not found?
I just wrote a small program to create a directory and invoke removexattr on it and I can see removexattr is sent to userspace.
Here are the fuse logs.

unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 116314
   unique: 2, success, outsize: 120
unique: 3, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 116314
   unique: 3, error: -38 (Function not implemented), outsize: 16
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 42, pid: 116314
   unique: 4, success, outsize: 144
unique: 5, opcode: LOOKUP (1), nodeid: 1, insize: 44, pid: 67887
   unique: 5, success, outsize: 144
unique: 6, opcode: MKDIR (9), nodeid: 1, insize: 52, pid: 67887
   unique: 6, success, outsize: 144
unique: 7, opcode: REMOVEXATTR (24), nodeid: 3, insize: 45, pid: 67887
   unique: 7, error: -61 (No data available), outsize: 16

On Tue, Nov 29, 2016 at 4:05 AM, Stef Bon <[hidden email]> wrote:
2016-11-28 22:51 GMT + 01: 00 Joseph Jobi <[hidden email]>:
> I have seen Unnecessary removexattr () calls in large numbers coming to fuse
> when the file does not have any extended attributes, but have not tracked
> down what exactly triggering Those calls.

That was unexpected. Fuse does not send removexattr to userspace When
a extended attribute is not found. That would be usefull double:
you do not have to delete a xattr if it is not there. What do you
reply to the VFS?

>
> About the new ACL option you Mentioned, Is that a file system wide option or
> something we can do on a per file basis?

I'm afraid I do not understand you, or you me ...
Disabling the posix acl's on a filesystem will preventinfo getxattr
calls for the system.posix_acl_access xattr, but you still willhave
extended attributes, to implement your own extended attributes on your
filesystem. This will get you get rid of most of the calls getxattr
you Mentioned in the example. You can test your FS and log the name of
the xattr.

Better is to file a bug / suggestion on the issue tracker as mentioned.

Stef


------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Stef Bon-2
2016-11-29 16:28 GMT+01:00 Joseph Jobi <[hidden email]>:
> How does Fuse know not to send removexattr to userspace when an extended
> attribute is not found?
> I just wrote a small program to create a directory and invoke removexattr on
> it and I can see removexattr is sent to userspace which is obviously a bug. But that's not the case.

Yes of course. When you program removexattr on your fs, the kernel
sends this to userspace. But in your previous
posts you were not writing anything about doing removexattr on your fs
(I've read them all). You were talking about
the command "ls" which causes a lot of getxattr calls, which is the
default behaviour and not a bug.
I thought the kernel just sends them for no reason.

Please file a bug/question and be so complete and consistent as
possible. This will prevent any misunderstanding.

Stef

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Joseph Jobi
I did not mean to say these are bugs, but something fuse could be optimized further.
If fuse can cache the fact a file does not have extended attributes (as part of a prior getattr/lookup request), then any subsequent getxattr()/removexattr() calls could be responded without consulting the userspace (until of course an extended attribute is added to the file).
Currently, the common case where files do not have extended attributes are being affected by these unnecessary getxattr/removexattr calls.
I have not tracked down the applications/commands which invoke unnecessary removexattr() calls, but there are some as I have seen while testing my file system.
I'll file a buf report as you suggested.  Thanks a lot for your time!


On Tue, Nov 29, 2016 at 8:24 AM, Stef Bon <[hidden email]> wrote:
2016-11-29 16:28 GMT+01:00 Joseph Jobi <[hidden email]>:
> How does Fuse know not to send removexattr to userspace when an extended
> attribute is not found?
> I just wrote a small program to create a directory and invoke removexattr on
> it and I can see removexattr is sent to userspace which is obviously a bug. But that's not the case.

Yes of course. When you program removexattr on your fs, the kernel
sends this to userspace. But in your previous
posts you were not writing anything about doing removexattr on your fs
(I've read them all). You were talking about
the command "ls" which causes a lot of getxattr calls, which is the
default behaviour and not a bug.
I thought the kernel just sends them for no reason.

Please file a bug/question and be so complete and consistent as
possible. This will prevent any misunderstanding.

Stef


------------------------------------------------------------------------------

--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Nikolaus Rath
In reply to this post by Joseph Jobi
On Nov 28 2016, Joseph Jobi <jobi-d/eNp5y7OX9Wk0Htik3J/[hidden email]> wrote:
>> Isn't this exactly what FUSE does if you set keep_cache to zero?
>> Contents are cached while the file is open, but discarded when all fds
>> have been closed.
>
> Currently, FUSE invalidates pages on open, not on close.

Looking at the kernel code that's true, interesting. I've just made this
a little more clear in the libfuse documentation.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Stef Bon-2
In reply to this post by Joseph Jobi
2016-11-29 17:34 GMT+01:00 Joseph Jobi <[hidden email]>:

> I did not mean to say these are bugs, but something fuse could be optimized
> further.
> If fuse can cache the fact a file does not have extended attributes (as part
> of a prior getattr/lookup request), then any subsequent
> getxattr()/removexattr() calls could be responded without consulting the
> userspace (until of course an extended attribute is added to the file).
> Currently, the common case where files do not have extended attributes are
> being affected by these unnecessary getxattr/removexattr calls.
> I have not tracked down the applications/commands which invoke unnecessary
> removexattr() calls, but there are some as I have seen while testing my file
> system.
> I'll file a buf report as you suggested.  Thanks a lot for your time!

Ok. Well I understand now what you suggest. That's not something easy
you talk about.
In the kernel every inode has it's own inode operations, and getxattr,
listxattr etc are part of those.

Well the kernel fuse module does assign every inode the same inode
operations (fs/fuse/dir.c, line 1924).
Having different ops and have custom made operations is pretty
complex. So yes possible, doable and worth the effort is another
story.

Stef

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Nikolaus Rath
On Nov 30 2016, Stef Bon <[hidden email]> wrote:

> 2016-11-29 17:34 GMT+01:00 Joseph Jobi <jobi-d/eNp5y7OX9Wk0Htik3J/[hidden email]>:
>> I did not mean to say these are bugs, but something fuse could be optimized
>> further.
>> If fuse can cache the fact a file does not have extended attributes (as part
>> of a prior getattr/lookup request), then any subsequent
>> getxattr()/removexattr() calls could be responded without consulting the
>> userspace (until of course an extended attribute is added to the file).
>> Currently, the common case where files do not have extended attributes are
>> being affected by these unnecessary getxattr/removexattr calls.
>> I have not tracked down the applications/commands which invoke unnecessary
>> removexattr() calls, but there are some as I have seen while testing my file
>> system.
>> I'll file a buf report as you suggested.  Thanks a lot for your time!
>
> Ok. Well I understand now what you suggest. That's not something easy
> you talk about.
> In the kernel every inode has it's own inode operations, and getxattr,
> listxattr etc are part of those.
>
> Well the kernel fuse module does assign every inode the same inode
> operations (fs/fuse/dir.c, line 1924).
> Having different ops and have custom made operations is pretty
> complex. So yes possible, doable and worth the effort is another
> story.

His idea is to have a way to tell the FUSE kernel module that some
inodes don't have xattrs, so that any xattr requests for these inodes
can be handled in-kernel without being send to the userspace
process. This doesn't require having different inode operations for
different inodes.



Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: requesting feedback on a few optimizations for fuse

Stef Bon-2
2016-11-30 18:09 GMT+01:00 Nikolaus Rath <[hidden email]>:
> On Nov 30 2016, Stef Bon <[hidden email]> wrote:

>> Well the kernel fuse module does assign every inode the same inode
>> operations (fs/fuse/dir.c, line 1924).
>> Having different ops and have custom made operations is pretty
>> complex. So yes possible, doable and worth the effort is another
>> story.
>
> His idea is to have a way to tell the FUSE kernel module that some
> inodes don't have xattrs, so that any xattr requests for these inodes
> can be handled in-kernel without being send to the userspace
> process. This doesn't require having different inode operations for
> different inodes.
>
>
I know. There are ways to do this without having custom inode
operations, an extra flag added
per inode.

But hey the whole problem described that the kernel sends a lot of
xattr related requests to userspace
has to do with acl checking using extended attributes.
Disabling this during initialization will also do the trick in the
first place. It will you get rid of the 2 extra calls
for xattr. Your fs can still implement the own extended attributes.
If and only if you still want acl checking based upon xattr
(posix_acl_access etc) where you know a lot
(and not just a few)  inodes do not have xattr, a check in the kernel
module would be an outcome.
But then realize you have to rewrite the checking for access using
extended attributes. For inodes without
xattr fallback on the default permissions checking.

Stef

------------------------------------------------------------------------------
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...