AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071025165225.01df200c@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<jonathan.goldick@onstor.com>,<eric.barrett@onstor.com>,<maxim.kozlovsky@onstor.com>,<huy.duong@onstor.com>,<csgroup@onstor.com>,<dl-se@onstor.com>,<dl-software@onstor.com>,<dl-qa@onstor.com>,<narayan.venkat@onstor.com>,<joshua.goldenhar@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E063836EC@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 25 Oct 2007 16:54:40 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>
Cc: "Eric Barrett" <eric.barrett@onstor.com>, "Maxim Kozlovsky"
 <maxim.kozlovsky@onstor.com>, "Huy Duong" <huy.duong@onstor.com>,
 "dl-Customer Service Group" <csgroup@onstor.com>, "dl-se"
 <dl-se@onstor.com>, "dl-Software" <dl-software@onstor.com>, "dl-QA"
 <dl-qa@onstor.com>, "Narayan Venkat" <narayan.venkat@onstor.com>, "Joshua
 Goldenhar" <joshua.goldenhar@onstor.com>
Subject: Re: Enabling/Disabling NFS shares
Message-ID: <20071025165440.45f836b1@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E063836EC@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E063836A0@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836A9@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836AE@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836B3@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836C5@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836CB@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836D3@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E063836EC@onstor-exch02.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 Thu, 25 Oct 2007 16:05:35 -0700 "Jonathan Goldick"
<jonathan.goldick@onstor.com> wrote:

[snippage]

> It's not a great management API to be able to enable/disable only one
> protocol 

[snip]

Yes it is.  In fact I might even say it's the best management API.


> 
> 
> 
> _____________________________________________
> From: Eric Barrett 
> Sent: Thursday, October 25, 2007 3:54 PM
> To: Maxim Kozlovsky; Jonathan Goldick; Huy Duong; dl-Customer Service
> Group; dl-se; dl-Software; dl-QA
> Cc: Narayan Venkat; Joshua Goldenhar
> Subject: RE: Enabling/Disabling NFS shares
> 
> That, and "vsvr disable" and "vol offline" tend to have lots of
> dependencies, and be very slow, so usually the system is down before
> you can finish them.  So if we get rid of the "nfs share disable"
> commands, we need to ensure "vsvr disable" takes effect immediately,
> or at least is remembered after reboot even if the system crashes a
> couple of seconds into the disable process.
> 
> 
> _____________________________________________ 
> From: 	Maxim Kozlovsky  
> Sent:	Thursday, October 25, 2007 3:52 PM
> To:	Jonathan Goldick; Huy Duong; dl-Customer Service Group;
> dl-se; dl-Software; dl-QA
> Cc:	Narayan Venkat; Joshua Goldenhar
> Subject:	RE: Enabling/Disabling NFS shares
> 
> What if you have a multiprotocol volume and only NFS clients cause a
> crash? Disabling NFS shares allows CIFS users to continue working
> until the problem is fixed. Or if you know the client, you can
> disable only affected share.
> 
> _____________________________________________
> From: Jonathan Goldick 
> Sent: Thursday, October 25, 2007 3:50 PM
> To: Maxim Kozlovsky; Huy Duong; dl-Customer Service Group; dl-se;
> dl-Software; dl-QA
> Cc: Narayan Venkat; Joshua Goldenhar
> Subject: RE: Enabling/Disabling NFS shares
> 
> The same thing is achieved by 'volume offline" or "vsvr disable" or
> disabling the IP addresses and it takes all protocols into account.
> 
> 
> _____________________________________________
> From: Maxim Kozlovsky 
> Sent: Thursday, October 25, 2007 3:42 PM
> To: Huy Duong; Jonathan Goldick; dl-Customer Service Group; dl-se;
> dl-Software; dl-QA
> Cc: Narayan Venkat; Joshua Goldenhar
> Subject: RE: Enabling/Disabling NFS shares
> 
> CIFS clients usually don't try to reconnect and do exactly the same
> thing after a failure. They know better - after all, the product was
> developed by Microsoft.
> 
> _____________________________________________
> From: Huy Duong 
> Sent: Thursday, October 25, 2007 3:40 PM
> To: Maxim Kozlovsky; Jonathan Goldick; dl-Customer Service Group;
> dl-se; dl-Software; dl-QA
> Cc: Narayan Venkat; Joshua Goldenhar
> Subject: RE: Enabling/Disabling NFS shares
> 
> WE should have one or CIFS now that you mention it :-) 
> 
> _____________________________________________
> From: Maxim Kozlovsky 
> Sent: Thursday, October 25, 2007 3:39 PM
> To: Jonathan Goldick; dl-Customer Service Group; dl-se; dl-Software;
> dl-QA
> Cc: Narayan Venkat; Joshua Goldenhar
> Subject: RE: Enabling/Disabling NFS shares
> 
> I think it was useful when we entered a crash loop because of a bug in
> NFS. Disabling a share prevents a client from connecting and crashing
> the system. Since the occurrences of NFS crash loops became much less
> frequent, the command lost most of its usefulness.
> 
> (I think we should preserve it, since when we will go to systemx we
> are bound to have some crash loops. :-) )
> 
> _____________________________________________
> From: Jonathan Goldick 
> Sent: Thursday, October 25, 2007 3:34 PM
> To: dl-Customer Service Group; dl-se; dl-Software; dl-QA
> Cc: Narayan Venkat; Joshua Goldenhar
> Subject: Enabling/Disabling NFS shares
> 
> This question is in the context of SystemX but about the current
> product.
> 
> We have a command to enable/disable NFS shares but not one for CIFS
> shares.  "nfs disable share [all | PATHNAME]"
> 
> Does anyone ever use these commands given that they do not prevent
> CIFS users from connecting and CIFS has no equivalent?  I'm trying to
> determine whether to preserve the functionality in SystemX given the
> limited value.
> 
> Unless I hear otherwise, this is going away in SystemX.
> 
