From: Arun R. <aru...@ie...> - 2009-09-23 17:44:41
|
Hello Friends, Background --------------- I am currently developing a Fuse FS using the low level calls (my basis has been the hello_ll example as opposed to the fusexmp_fh to improve performance for my specific application). My application does a large number of opens and does a short reads and and writes. My choices of design for the application were either to use Linux inotify or create a fuse based FS, with the goal that as soon as a file has been created/changed I become aware and do some processing on it. However with Fuse I can analyze the data being written out or read and thus make a more elegant solution. My hope is that I can use Fuse since it gives me exactly what I want for everything else I have to build a kludge, but I am having some performance issues sigh. I am running on a 64 bit dual core Intel processor with CentOS and I am using Fuse 2.7.4 I am finding that the number of voluntary context switches the application makes while writing to the Fuse FS is very high. I also find that the most expensive degradation comes surprisingly during the open call (the user application is just doing a simple fopen (filename, "+a"). While I understand and expect context switches to be high I did not expect the degradation (2X over the application writing directly to the same underlying ext3 filesystem). I turned off atime writing using -noatime during mount. I also stubbed out the Fuse file system side call to sync. I tracked that the number of calls to attribute is correct (before each write call for size). But as I said the bottleneck for me seems to be in the open calls. My lookup is very simple and is not the bottleneck. I am mystified by the 2X degradation on repeated open/close calls and would like to hear other's thoughts on similar experience if any. I am sure I am overlooking the obvious L on my side. Thanks, -arun |
From: Paul S. <pau...@up...> - 2009-09-24 11:56:58
|
Hi. Did you set fuse_entry_param->attr_timeout and fuse_entry_param->entry_timeout to something sensible like 300 (or more) in lookup,mknod/create ? This is provided that nothing else can modify the under lying data and cause corruption. Setting these did make a huge difference on my filesystem. Regards Paul Quoting Arun Ramachandran <aru...@ie...>: > Hello Friends, > > > > Background > > --------------- > > > > I am currently developing a Fuse FS using the low level calls (my basis has > been the hello_ll example as opposed to the fusexmp_fh to improve > performance for my specific application). My application does a large number > of opens and does a short reads and and writes. > > > > My choices of design for the application were either to use Linux inotify > or create a fuse based FS, with the goal that as soon as a file has been > created/changed I become aware and do some processing on it. However with > Fuse I can analyze the data being written out or read and thus make a more > elegant solution. My hope is that I can use Fuse since it gives me exactly > what I want for everything else I have to build a kludge, but I am having > some performance issues sigh. > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > using Fuse 2.7.4 > > > > I am finding that the number of voluntary context switches the application > makes while writing to the Fuse FS is very high. I also find that the most > expensive degradation comes surprisingly during the open call (the user > application is just doing a simple fopen (filename, "+a"). While I > understand and expect context switches to be high I did not expect the > degradation (2X over the application writing directly to the same underlying > ext3 filesystem). > > > > I turned off atime writing using -noatime during mount. I also stubbed out > the Fuse file system side call to sync. I tracked that the number of calls > to attribute is correct (before each write call for size). But as I said the > bottleneck for me seems to be in the open calls. My lookup is very simple > and is not the bottleneck. > > > > I am mystified by the 2X degradation on repeated open/close calls and would > like to hear other's thoughts on similar experience if any. I am sure I am > overlooking the obvious L on my side. > > > > Thanks, > > > > -arun > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. |
From: Arun R. <ar...@cu...> - 2009-09-24 16:46:14
|
Hi Paul, Thanks, unfortunately I did that in lookup. Since the file is guaranteed to exist the calls do not hit mknod or create. -arun -----Original Message----- From: Paul Schutte [mailto:pau...@up...] Sent: Thursday, September 24, 2009 4:56 AM To: Arun Ramachandran Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Hi. Did you set fuse_entry_param->attr_timeout and fuse_entry_param->entry_timeout to something sensible like 300 (or more) in lookup,mknod/create ? This is provided that nothing else can modify the under lying data and cause corruption. Setting these did make a huge difference on my filesystem. Regards Paul Quoting Arun Ramachandran <aru...@ie...>: > Hello Friends, > > > > Background > > --------------- > > > > I am currently developing a Fuse FS using the low level calls (my basis has > been the hello_ll example as opposed to the fusexmp_fh to improve > performance for my specific application). My application does a large number > of opens and does a short reads and and writes. > > > > My choices of design for the application were either to use Linux inotify > or create a fuse based FS, with the goal that as soon as a file has been > created/changed I become aware and do some processing on it. However with > Fuse I can analyze the data being written out or read and thus make a more > elegant solution. My hope is that I can use Fuse since it gives me exactly > what I want for everything else I have to build a kludge, but I am having > some performance issues sigh. > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > using Fuse 2.7.4 > > > > I am finding that the number of voluntary context switches the application > makes while writing to the Fuse FS is very high. I also find that the most > expensive degradation comes surprisingly during the open call (the user > application is just doing a simple fopen (filename, "+a"). While I > understand and expect context switches to be high I did not expect the > degradation (2X over the application writing directly to the same underlying > ext3 filesystem). > > > > I turned off atime writing using -noatime during mount. I also stubbed out > the Fuse file system side call to sync. I tracked that the number of calls > to attribute is correct (before each write call for size). But as I said the > bottleneck for me seems to be in the open calls. My lookup is very simple > and is not the bottleneck. > > > > I am mystified by the 2X degradation on repeated open/close calls and would > like to hear other's thoughts on similar experience if any. I am sure I am > overlooking the obvious L on my side. > > > > Thanks, > > > > -arun > > > > ---------------------------------------------------------------------------- -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. |
From: chris m. <chr...@gm...> - 2009-09-25 06:28:22
|
Open may be expensive because you are not taking advantage of the kernel dentry cache that FUSE allows for. A nice imperical test that you can run... Do the same tests where you noted a slow down but run them inside of a deep directory tree. For example: > /1/2/3/4/5/6/7/8 > That should force many many context switches for the lookup call, resulting in an even larger MUCH more noticeable slowdown. After the problem is identified solving it will be next :) Good Luck, -Chris On Thu, Sep 24, 2009 at 12:17 PM, Arun Ramachandran < ar...@cu...> wrote: > Hi Paul, > > Thanks, unfortunately I did that in lookup. Since the file is guaranteed > to > exist the calls do not hit mknod or create. > > -arun > > > -----Original Message----- > From: Paul Schutte [mailto:pau...@up...] > Sent: Thursday, September 24, 2009 4:56 AM > To: Arun Ramachandran > Cc: fus...@li... > Subject: Re: [fuse-devel] File Open performance > > Hi. > > Did you set fuse_entry_param->attr_timeout and > fuse_entry_param->entry_timeout > to something sensible like 300 (or more) in lookup,mknod/create ? > > This is provided that nothing else can modify the under lying data and > cause corruption. > > Setting these did make a huge difference on my filesystem. > > Regards > Paul > > Quoting Arun Ramachandran <aru...@ie...>: > > > Hello Friends, > > > > > > > > Background > > > > --------------- > > > > > > > > I am currently developing a Fuse FS using the low level calls (my basis > has > > been the hello_ll example as opposed to the fusexmp_fh to improve > > performance for my specific application). My application does a large > number > > of opens and does a short reads and and writes. > > > > > > > > My choices of design for the application were either to use Linux > inotify > > or create a fuse based FS, with the goal that as soon as a file has > been > > created/changed I become aware and do some processing on it. However with > > Fuse I can analyze the data being written out or read and thus make a > more > > elegant solution. My hope is that I can use Fuse since it gives me > exactly > > what I want for everything else I have to build a kludge, but I am having > > some performance issues sigh. > > > > > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > > using Fuse 2.7.4 > > > > > > > > I am finding that the number of voluntary context switches the > application > > makes while writing to the Fuse FS is very high. I also find that the > most > > expensive degradation comes surprisingly during the open call (the user > > application is just doing a simple fopen (filename, "+a"). While I > > understand and expect context switches to be high I did not expect the > > degradation (2X over the application writing directly to the same > underlying > > ext3 filesystem). > > > > > > > > I turned off atime writing using -noatime during mount. I also stubbed > out > > the Fuse file system side call to sync. I tracked that the number of > calls > > to attribute is correct (before each write call for size). But as I said > the > > bottleneck for me seems to be in the open calls. My lookup is very simple > > and is not the bottleneck. > > > > > > > > I am mystified by the 2X degradation on repeated open/close calls and > would > > like to hear other's thoughts on similar experience if any. I am sure I > am > > overlooking the obvious L on my side. > > > > > > > > Thanks, > > > > > > > > -arun > > > > > > > > > > ---------------------------------------------------------------------------- > -- > > Come build with us! The BlackBerry® Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9-12, 2009. Register > now! > > http://p.sf.net/sfu/devconf > > _______________________________________________ > > fuse-devel mailing list > > fus...@li... > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > > > > This message and attachments are subject to a disclaimer. Please refer > to www.it.up.ac.za/documentation/governance/disclaimer/ for full > details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule > onderhewig. Volledige besonderhede is by > www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > |
From: Arun R. <ar...@cu...> - 2009-09-25 07:12:22
|
When I turn on the -d option and observe, the only "OPCODES" I see being called are OPEN, FLUSH, RELEASE. So I guess I have not reached the second landmine yet !. -arun From: chris meyers [mailto:chr...@gm...] Sent: Thursday, September 24, 2009 11:28 PM To: ar...@cu... Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Open may be expensive because you are not taking advantage of the kernel dentry cache that FUSE allows for. A nice imperical test that you can run... Do the same tests where you noted a slow down but run them inside of a deep directory tree. For example: /1/2/3/4/5/6/7/8 That should force many many context switches for the lookup call, resulting in an even larger MUCH more noticeable slowdown. After the problem is identified solving it will be next :) Good Luck, -Chris On Thu, Sep 24, 2009 at 12:17 PM, Arun Ramachandran <ar...@cu...> wrote: Hi Paul, Thanks, unfortunately I did that in lookup. Since the file is guaranteed to exist the calls do not hit mknod or create. -arun -----Original Message----- From: Paul Schutte [mailto:pau...@up...] Sent: Thursday, September 24, 2009 4:56 AM To: Arun Ramachandran Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Hi. Did you set fuse_entry_param->attr_timeout and fuse_entry_param->entry_timeout to something sensible like 300 (or more) in lookup,mknod/create ? This is provided that nothing else can modify the under lying data and cause corruption. Setting these did make a huge difference on my filesystem. Regards Paul Quoting Arun Ramachandran <aru...@ie...>: > Hello Friends, > > > > Background > > --------------- > > > > I am currently developing a Fuse FS using the low level calls (my basis has > been the hello_ll example as opposed to the fusexmp_fh to improve > performance for my specific application). My application does a large number > of opens and does a short reads and and writes. > > > > My choices of design for the application were either to use Linux inotify > or create a fuse based FS, with the goal that as soon as a file has been > created/changed I become aware and do some processing on it. However with > Fuse I can analyze the data being written out or read and thus make a more > elegant solution. My hope is that I can use Fuse since it gives me exactly > what I want for everything else I have to build a kludge, but I am having > some performance issues sigh. > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > using Fuse 2.7.4 > > > > I am finding that the number of voluntary context switches the application > makes while writing to the Fuse FS is very high. I also find that the most > expensive degradation comes surprisingly during the open call (the user > application is just doing a simple fopen (filename, "+a"). While I > understand and expect context switches to be high I did not expect the > degradation (2X over the application writing directly to the same underlying > ext3 filesystem). > > > > I turned off atime writing using -noatime during mount. I also stubbed out > the Fuse file system side call to sync. I tracked that the number of calls > to attribute is correct (before each write call for size). But as I said the > bottleneck for me seems to be in the open calls. My lookup is very simple > and is not the bottleneck. > > > > I am mystified by the 2X degradation on repeated open/close calls and would > like to hear other's thoughts on similar experience if any. I am sure I am > overlooking the obvious L on my side. > > > > Thanks, > > > > -arun > > > > ---------------------------------------------------------------------------- -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ fuse-devel mailing list fus...@li... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: Arun R. <ar...@cu...> - 2009-09-25 17:21:59
|
On some more inspection of my woes, I would like to ask a more targeted question. Before each write the Kernel calls GetAttr. Is there any way this can be avoided. I am guessing it is calling this to get the latest size, but it should have the correct size ... Thanks, -arun From: chris meyers [mailto:chr...@gm...] Sent: Thursday, September 24, 2009 11:28 PM To: ar...@cu... Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Open may be expensive because you are not taking advantage of the kernel dentry cache that FUSE allows for. A nice imperical test that you can run... Do the same tests where you noted a slow down but run them inside of a deep directory tree. For example: /1/2/3/4/5/6/7/8 That should force many many context switches for the lookup call, resulting in an even larger MUCH more noticeable slowdown. After the problem is identified solving it will be next :) Good Luck, -Chris On Thu, Sep 24, 2009 at 12:17 PM, Arun Ramachandran <ar...@cu...> wrote: Hi Paul, Thanks, unfortunately I did that in lookup. Since the file is guaranteed to exist the calls do not hit mknod or create. -arun -----Original Message----- From: Paul Schutte [mailto:pau...@up...] Sent: Thursday, September 24, 2009 4:56 AM To: Arun Ramachandran Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Hi. Did you set fuse_entry_param->attr_timeout and fuse_entry_param->entry_timeout to something sensible like 300 (or more) in lookup,mknod/create ? This is provided that nothing else can modify the under lying data and cause corruption. Setting these did make a huge difference on my filesystem. Regards Paul Quoting Arun Ramachandran <aru...@ie...>: > Hello Friends, > > > > Background > > --------------- > > > > I am currently developing a Fuse FS using the low level calls (my basis has > been the hello_ll example as opposed to the fusexmp_fh to improve > performance for my specific application). My application does a large number > of opens and does a short reads and and writes. > > > > My choices of design for the application were either to use Linux inotify > or create a fuse based FS, with the goal that as soon as a file has been > created/changed I become aware and do some processing on it. However with > Fuse I can analyze the data being written out or read and thus make a more > elegant solution. My hope is that I can use Fuse since it gives me exactly > what I want for everything else I have to build a kludge, but I am having > some performance issues sigh. > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > using Fuse 2.7.4 > > > > I am finding that the number of voluntary context switches the application > makes while writing to the Fuse FS is very high. I also find that the most > expensive degradation comes surprisingly during the open call (the user > application is just doing a simple fopen (filename, "+a"). While I > understand and expect context switches to be high I did not expect the > degradation (2X over the application writing directly to the same underlying > ext3 filesystem). > > > > I turned off atime writing using -noatime during mount. I also stubbed out > the Fuse file system side call to sync. I tracked that the number of calls > to attribute is correct (before each write call for size). But as I said the > bottleneck for me seems to be in the open calls. My lookup is very simple > and is not the bottleneck. > > > > I am mystified by the 2X degradation on repeated open/close calls and would > like to hear other's thoughts on similar experience if any. I am sure I am > overlooking the obvious L on my side. > > > > Thanks, > > > > -arun > > > > ---------------------------------------------------------------------------- -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ fuse-devel mailing list fus...@li... https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: chris m. <chr...@gm...> - 2009-09-27 16:43:30
|
Maybe the function you are looking for is: fuse_reply_attr(). An example of it being used can be found in dbfs (look in kernel.org's git repository for the dbfs). I believe fuse_reply_attr() will send the attribute back into the fuse kernel filesystem and cache the supplied attribute information for the specified period of time. -Chris On Fri, Sep 25, 2009 at 1:20 PM, Arun Ramachandran <ar...@cu... > wrote: > On some more inspection of my woes, I would like to ask a more targeted > question. Before each write the Kernel calls GetAttr. Is there any way this > can be avoided. I am guessing it is calling this to get the latest size, > but > it should have the correct size ... > > > > Thanks, > > > > -arun > > > > > > From: chris meyers [mailto:chr...@gm...] > Sent: Thursday, September 24, 2009 11:28 PM > To: ar...@cu... > Cc: fus...@li... > Subject: Re: [fuse-devel] File Open performance > > > > Open may be expensive because you are not taking advantage of the kernel > dentry cache that FUSE allows for. A nice imperical test that you can > run... > Do the same tests where you noted a slow down but run them inside of a deep > directory tree. For example: > > /1/2/3/4/5/6/7/8 > > That should force many many context switches for the lookup call, resulting > in an even larger MUCH more noticeable slowdown. After the problem is > identified solving it will be next :) > > Good Luck, > -Chris > > On Thu, Sep 24, 2009 at 12:17 PM, Arun Ramachandran > <ar...@cu...> wrote: > > Hi Paul, > > Thanks, unfortunately I did that in lookup. Since the file is guaranteed > to > exist the calls do not hit mknod or create. > > -arun > > > > -----Original Message----- > From: Paul Schutte [mailto:pau...@up...] > Sent: Thursday, September 24, 2009 4:56 AM > To: Arun Ramachandran > Cc: fus...@li... > Subject: Re: [fuse-devel] File Open performance > > Hi. > > Did you set fuse_entry_param->attr_timeout and > fuse_entry_param->entry_timeout > to something sensible like 300 (or more) in lookup,mknod/create ? > > This is provided that nothing else can modify the under lying data and > cause corruption. > > Setting these did make a huge difference on my filesystem. > > Regards > Paul > > Quoting Arun Ramachandran <aru...@ie...>: > > > Hello Friends, > > > > > > > > Background > > > > --------------- > > > > > > > > I am currently developing a Fuse FS using the low level calls (my basis > has > > been the hello_ll example as opposed to the fusexmp_fh to improve > > performance for my specific application). My application does a large > number > > of opens and does a short reads and and writes. > > > > > > > > My choices of design for the application were either to use Linux > inotify > > or create a fuse based FS, with the goal that as soon as a file has > been > > created/changed I become aware and do some processing on it. However with > > Fuse I can analyze the data being written out or read and thus make a > more > > elegant solution. My hope is that I can use Fuse since it gives me > exactly > > what I want for everything else I have to build a kludge, but I am having > > some performance issues sigh. > > > > > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > > using Fuse 2.7.4 > > > > > > > > I am finding that the number of voluntary context switches the > application > > makes while writing to the Fuse FS is very high. I also find that the > most > > expensive degradation comes surprisingly during the open call (the user > > application is just doing a simple fopen (filename, "+a"). While I > > understand and expect context switches to be high I did not expect the > > degradation (2X over the application writing directly to the same > underlying > > ext3 filesystem). > > > > > > > > I turned off atime writing using -noatime during mount. I also stubbed > out > > the Fuse file system side call to sync. I tracked that the number of > calls > > to attribute is correct (before each write call for size). But as I said > the > > bottleneck for me seems to be in the open calls. My lookup is very simple > > and is not the bottleneck. > > > > > > > > I am mystified by the 2X degradation on repeated open/close calls and > would > > like to hear other's thoughts on similar experience if any. I am sure I > am > > overlooking the obvious L on my side. > > > > > > > > Thanks, > > > > > > > > -arun > > > > > > > > > > ---------------------------------------------------------------------------- > -- > > Come build with us! The BlackBerry® Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9-12, 2009. Register > now! > > http://p.sf.net/sfu/devconf > > _______________________________________________ > > fuse-devel mailing list > > fus...@li... > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > > > > This message and attachments are subject to a disclaimer. Please refer > to www.it.up.ac.za/documentation/governance/disclaimer/ for full > details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule > onderhewig. Volledige besonderhede is by > www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. > > > > > ---------------------------------------------------------------------------- > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > |
From: Arun R. <aru...@ie...> - 2009-09-27 17:09:43
|
Chris, Thanks. Fuse_reply_attr works perfectly for me on reads. That is getAttr is not called beyond the first lookup. So the kernel is caching it properly and I am happy. However on open for writes it is a different story, which is after the open call a call to GetAttr is made, regardless of setting the value. My only hope is one of two things -In open call I do a fstat and then tuck it in to file_info->fh structure and hope that the GetAttr (which has a comment that struct fuse_file_info* is null in 2.7.x) gets that as one of the arguments. This will help reduce some lookup but does not avoid the context switching. - The best option is for the kernel is to have an additional field in struct fuse_file_info that gets filled in by fstat by the user similar to fh (or null, which will make it backward compatible) that it then uses. This of course will reduce the context call and make me happy. Thanks again, -arun From: chris meyers [mailto:chr...@gm...] Sent: Sunday, September 27, 2009 9:43 AM To: ar...@cu... Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Maybe the function you are looking for is: fuse_reply_attr(). An example of it being used can be found in dbfs (look in kernel.org's git repository for the dbfs). I believe fuse_reply_attr() will send the attribute back into the fuse kernel filesystem and cache the supplied attribute information for the specified period of time. -Chris On Fri, Sep 25, 2009 at 1:20 PM, Arun Ramachandran <ar...@cu...> wrote: On some more inspection of my woes, I would like to ask a more targeted question. Before each write the Kernel calls GetAttr. Is there any way this can be avoided. I am guessing it is calling this to get the latest size, but it should have the correct size ... Thanks, -arun From: chris meyers [mailto:chr...@gm...] Sent: Thursday, September 24, 2009 11:28 PM To: ar...@cu... Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Open may be expensive because you are not taking advantage of the kernel dentry cache that FUSE allows for. A nice imperical test that you can run... Do the same tests where you noted a slow down but run them inside of a deep directory tree. For example: /1/2/3/4/5/6/7/8 That should force many many context switches for the lookup call, resulting in an even larger MUCH more noticeable slowdown. After the problem is identified solving it will be next :) Good Luck, -Chris On Thu, Sep 24, 2009 at 12:17 PM, Arun Ramachandran <ar...@cu...> wrote: Hi Paul, Thanks, unfortunately I did that in lookup. Since the file is guaranteed to exist the calls do not hit mknod or create. -arun -----Original Message----- From: Paul Schutte [mailto:pau...@up...] Sent: Thursday, September 24, 2009 4:56 AM To: Arun Ramachandran Cc: fus...@li... Subject: Re: [fuse-devel] File Open performance Hi. Did you set fuse_entry_param->attr_timeout and fuse_entry_param->entry_timeout to something sensible like 300 (or more) in lookup,mknod/create ? This is provided that nothing else can modify the under lying data and cause corruption. Setting these did make a huge difference on my filesystem. Regards Paul Quoting Arun Ramachandran <aru...@ie...>: > Hello Friends, > > > > Background > > --------------- > > > > I am currently developing a Fuse FS using the low level calls (my basis has > been the hello_ll example as opposed to the fusexmp_fh to improve > performance for my specific application). My application does a large number > of opens and does a short reads and and writes. > > > > My choices of design for the application were either to use Linux inotify > or create a fuse based FS, with the goal that as soon as a file has been > created/changed I become aware and do some processing on it. However with > Fuse I can analyze the data being written out or read and thus make a more > elegant solution. My hope is that I can use Fuse since it gives me exactly > what I want for everything else I have to build a kludge, but I am having > some performance issues sigh. > > > > I am running on a 64 bit dual core Intel processor with CentOS and I am > using Fuse 2.7.4 > > > > I am finding that the number of voluntary context switches the application > makes while writing to the Fuse FS is very high. I also find that the most > expensive degradation comes surprisingly during the open call (the user > application is just doing a simple fopen (filename, "+a"). While I > understand and expect context switches to be high I did not expect the > degradation (2X over the application writing directly to the same underlying > ext3 filesystem). > > > > I turned off atime writing using -noatime during mount. I also stubbed out > the Fuse file system side call to sync. I tracked that the number of calls > to attribute is correct (before each write call for size). But as I said the > bottleneck for me seems to be in the open calls. My lookup is very simple > and is not the bottleneck. > > > > I am mystified by the 2X degradation on repeated open/close calls and would > like to hear other's thoughts on similar experience if any. I am sure I am > overlooking the obvious L on my side. > > > > Thanks, > > > > -arun > > > > ---------------------------------------------------------------------------- -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel > This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details. / Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar. ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ fuse-devel mailing list fus...@li... https://lists.sourceforge.net/lists/listinfo/fuse-devel ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ fuse-devel mailing list fus...@li... https://lists.sourceforge.net/lists/listinfo/fuse-devel |