AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20081118160910.7d3ebf10@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<eric.barrett@onstor.com>,<fredm@css.glasshouse.com>,<dl-cstech@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB5175D757B81@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 18 Nov 2008 16:09:54 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Eric Barrett <eric.barrett@onstor.com>
Cc: "Fred McFadden (Glasshouse)" <fredm@css.glasshouse.com>, dl-cstech
 <dl-cstech@onstor.com>
Subject: Re: nfs caching
Message-ID: <20081118160954.53642218@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB5175D757B81@exch1.onstor.net>
References: <482769BCFD004C139B6DE16A1208B0D5@lab.css.glasshouse.com>
	<20081118115217.6d3d5f3c@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5175D757B81@exch1.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 18 Nov 2008 12:12:28 -0800 Eric Barrett
<eric.barrett@onstor.com> wrote:

> Andy,
> 
> Your Linux client definitely has a sync/async mount option.  (Look in
> mount(8), not nfs(5); it's not NFS-specific.)  The default is always
> async, because sync cuts performance by about 90% in real-world
> scenarios, even for local storage.

You're correct, it's a general option.  I was looking in the NFS code
hence I didn't see it.  Synchronous semantics are also, of course,
settable on a per-file basis by individual apps, like databases.

> The customer is complaining that when they have multiple NFS clients,
> one doesn't see updates from the other right away.  This is a
> limitation of all NFS clients -- if you can set them up to not cache
> file attributes (via noac, which is basically equivalent to
> "actimeo=0,sync", or just "sync" itself -- they may be the same
> nowadays), it also means not caching writes, not to mention passing
> every repetitive system call through to the NFS layer.  So your
> performance goes to where you'd expect it to.  If you enable
> attribute caching in order to get user data caching back, now your
> server is not sending every readdir(2) to the NFS server, so one
> client doen't always immediately see updates that another client
> makes.
> 
> He can TRY setting "actimeo=0" by itself but, last I heard, the Linux
> nfsutils helpfully sets 'sync' in the background for you when they
> see this, so I doubt it will work.  And I think we already suggested
> that.  And it will still affect performance, a lot.

Yes, they can try async,noac  -- the performance impact will be
noticeable, but the content will be much more coherent-looking.  Again,
I think that they probably need to fine tune their options on the
clients for the desired performance targets, which is probably outside
of our support responsibility.

> Despite the customer's ire, the problem they are running into is
> actually something people have been running into since NFS and its
> predecessors were invented, and there's really no solution except to
> either take the performance hit or make the applications aware of the
> problem and behave accordingly (say, keep checking for a full minute
> before giving up and assuming the file isn't there).
> 
> -E
> 
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Tuesday, November 18, 2008 2:52 PM
> To: Fred McFadden (Glasshouse)
> Cc: dl-cstech
> Subject: Re: nfs caching
> 
> It's hard to answer something like this when it's all been left so
> vague.  They get a failure when they try to mount with async?  What is
> that error?  How, exactly, are they "mounting async"?  On my Linux
> client, there is no sync/async mount option.  How many clients do they
> have?  Do multiple clients access the same file at the same time?  For
> reading or for writing too?
> 
> And oh yeah, what Jonathan said, too.
> 
> Like any performance optimization exercise, a decent amount of work
> needs to be done to get it right.  I suggest they sign up for some PS
> so that we can get in there and do a proper job of it.  Otherwise they
> need to read their client documentation and figure it out for
> themselves.
> 
> On Tue, 18 Nov 2008 10:00:47 -0800 "Fred McFadden (Glasshouse)"
> <fredm@css.glasshouse.com> wrote:
> 
> > Limehouse Software case 10758
> > 
> > Customer has nfs performance concern.
> > 
> > Customer has declared the sync option on his nfs mount.
> > I advised him to not do that and his response is. (paraphrased):
> > ----------------------
> > The issue with the Cache being on is that it does not refresh quick
> > enough ..and was failing with the old mount settings.
> > 
> > Now it does not fail, but we have performance issues.
> > 
> > Can we speed up the cache at all to make it instant?
> > 
> > Can we use any of the settings below to help ?
> > 
> > Acregmin, acregmax, acdirmin, acdirmax, actimeo.
> > 
> > -----end of customer comment------
> > 
> > Linux client accessing large image files. 
> > Any thoughts on nfs mount options for caching?
> > ================
> > Thanks
> > Fred
> > 
> > 
