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
pgpecPcwD3dgC.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss