On Wed, Nov 01, 2006 at 04:00:43PM -0500, Torrey McMahon wrote:
> Spencer Shepler wrote:
> >On Wed, Adam Leventhal wrote:
> >  
> >>On Wed, Nov 01, 2006 at 01:17:02PM -0500, Torrey McMahon wrote:
> >>    
> >>>Is there going to be a method to override that on the import? I can see 
> >>>a situation where you want to import the pool for some kind of 
> >>>maintenance procedure but you don't want the iSCSI target to fire up 
> >>>automagically.
> >>>      
> >>There isn't -- to my knowledge -- a way to do this today for NFS shares.
> >>This would be a reasonable RFE that would apply to both NFS and iSCSI.
> >>    
> >
> >In the case of NFS, this can be dangerous if the "rest" of the NFS
> >server is allowed to come up and serve other filesystems.  The non-shared
> >filesystem will end up returning ESTALE errors to clients that are
> >active on that filesystem.  It should be an all or nothing selection...
> >  
> 
> Lets say server A has the pool with NFS shared, or iSCSI shared, 
> volumes. Server A exports the pool or goes down. Server B imports the pool.
> 
> Which clients would still be active on the filesystem(s)? The ones that 
> were mounting it when it was on Server A?

For NFS, it's possible (but likely suboptimal) for clients to be
configured to mount the filesystem from server A and fail over to
server B, assuming that the pool import can happen quickly enough for
them not to receive ENOENT.

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere

Attachment: pgpecPcwD3dgC.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to