Hi,

Yes--the impact of new api would be important to measure at this point.

Matt

----- Original Message -----
> From: "Frank Filz" <[email protected]>
> To: "Tushar Shinde" <[email protected]>, "J. Bruce Fields" 
> <[email protected]>,
> [email protected]
> Sent: Wednesday, April 13, 2016 11:43:26 AM
> Subject: Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow 
> compared to Linux kernel NFSv4
> 
> I'd be really interested in how this stacks up using V2.4-dev-11 (or later)
> with FSAL_VFS. That build includes my work to support multiple file
> descriptors, which ALSO includes streamlining the OPEN operation. Note that
> currently FSAL_VFS is the only FSAL to benefit from that streamlining, but
> anyone working a different FSAL would be encouraged to implement the
> extended FSAL API (support_ex and methods like open2). Note that I have yet
> to implement create2 which might help if your create load includes
> non-regular files.
> 
> The extended API holds the most opportunity in this area for FSALs other
> than FSAL_VFS that have the possibility of implementing open2 completely
> down into the underlying filesystem (the open2 method exposes the FSAL to
> all the semantics of the NFS v4 OPEN operation).
> 
> We have plans for subsequent performance attention to work at handling
> multiple operations from a single COMPOUND into a single FSAL call. One
> specific area of improvement would be explicit GETATTR handling as requested
> by the COMPOUND performed in the same call to the underlying filesystem as
> the associated operation (OPEN, READ, WRITE, etc). This would also benefit
> NFS v3 (by being able to manage the post op attributes the same way).
> 
> Thanks
> 
> Frank
> 
> > -----Original Message-----
> > From: Tushar Shinde [mailto:[email protected]]
> > Sent: Wednesday, April 13, 2016 3:21 AM
> > To: Tushar Shinde <[email protected]>; J. Bruce Fields
> > <[email protected]>; [email protected]
> > Subject: Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow
> > compared to Linux kernel NFSv4
> > 
> > I did test with Kernel nfs and Ganesha, With sync and NFS_Commit = True;
> > Following are results,
> > 
> > KNFSv4
> > ---------------------------------------------------------
> > Operation        total_ops-nsec                  ops/s
> > ---------------------------------------------------------
> > create           110000- 668159357063            164.631378
> > open             110000- 266032790536            413.482880
> > close            220000- 872624163550            252.113129
> > 
> > Ganesha V4
> > ---------------------------------------------------------
> > Operation        total_ops-nsec                  ops/s
> > ---------------------------------------------------------
> > create           110000- 694286669184            158.435989
> > open             110000- 408155570824            269.505066
> > close            220000- 1028802481561           213.840851
> > 
> > The time measured is in nsec by using clock_gettime(CLOCK_REALTIME) like,
> > start_timer();
> > open() or operation
> > stop_timer();
> > 
> > The open operation is very slow (About 30-34%), I am finding it
> consistently
> > slow across multiple runs. Please note there is no IO done no-read and no-
> > write, Just open and close.
> > In this open I had not used O_CREAT its only O_RDWR.
> > I observed cih_fh_cmpf is most frequenty called function, So I tried to
> > increase cache_sz and nparts but that did not resulted in significant
> change.
> > 
> > cache_inode/cache_inode_hash.c
> > 75         uint32_t cache_sz = 32767;      /* XXX */
> > 85         npart = cache_param.nparts;
> > 
> > I will debug this again, But till then, If you know any tunables which can
> affect
> > this code path please let me know.
> > 
> > 
> > Thank you,
> > Tushar.
> > 
> > 
> > 
> > 
> > On Tue, Apr 12, 2016 at 11:08 PM, Malahal Naineni <[email protected]>
> > wrote:
> > > Tushar Shinde [[email protected]] wrote:
> > >> I had used async with kernel and NFS_Commit = FALSE; with Ganesha.
> > >> Do you think still it will be unfair comparison?
> > >
> > > Usually NFS clients are smart and they send write with FILE_SYNC if
> > > they don't have any more writes. There are some clients (VMware I
> > > think) that do "write followed by commit" even if they have just one
> write.
> > > To avoid this follow on commit, ganesha syncs the data and tells the
> > > client about it with "NFS_Commit = True".
> > >
> > > Usually, we don't recommend "NFS_Commit = True" unless you have such
> > a
> > > client. Ganesha always honors commits and there is no way to mimic
> > > kernel NFS's async option.
> > >
> > > As others have commented, use "sync" and compare.
> > >
> > > Regards, Malahal.
> > >
> > 
> >
> ----------------------------------------------------------------------------
> --
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers
> > of your business applications. It resolves application problems quickly
> and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > _______________________________________________
> > Nfs-ganesha-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers
> of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Nfs-ganesha-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Nfs-ganesha-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Reply via email to