Hello Jason,
Thursday, December 7, 2006, 11:18:17 PM, you wrote:
JJWW Hi Luke,
JJWW That's terrific!
JJWW You know you might be able to tell ZFS which disks to look at. I'm not
JJWW sure. It would be interesting, if anyone with a Thumper could comment
JJWW on whether or not they see the import
I got around that some time ago with a little hack;
Maintain a directory with soft links to disks of interest:
ls -l .../mydsklist
total 50
lrwxrwxrwx 1 cx158393 staff 17 Apr 29 2006 c1t0d0s1 -
/dev/dsk/c1t0d0s1
lrwxrwxrwx 1 cx158393 staff 18 Apr 29 2006 c1t16d0s1 -
Hi Roch,
That's a pretty cool idea!
-J
On 12/8/06, Roch - PAE [EMAIL PROTECTED] wrote:
I got around that some time ago with a little hack;
Maintain a directory with soft links to disks of interest:
ls -l .../mydsklist
total 50
lrwxrwxrwx 1 cx158393 staff 17 Apr 29 2006 c1t0d0s1
Hi Luke,
That's terrific!
You know you might be able to tell ZFS which disks to look at. I'm not
sure. It would be interesting, if anyone with a Thumper could comment
on whether or not they see the import time issue. What are your load
times now with MPXIO?
Best Regards,
Jason
On 12/7/06,
I, too, experienced a long delay while importing a zpool on a second machine. I
do not have any filesystems in the pool. Just the Solaris 10 Operating system,
Emulex 10002DC HBA, and a 4884 LSI array (dual attached).
I don't have any file systems created but when STMS(mpxio) is enabled I see
as an alternative, I thaught this would be relevant to the
discussion:
Bug ID: 6478980
Synopsis: zfs should support automount property
In other words, do we really need to mount 1 FS in a
snap, or do we just need to system to be up quickly then
mount on demand
-r
If you share the file systems the time increases even further but as I
understand it that issue is being worked:
[EMAIL PROTECTED] # time zpool import zpool1
real 7h6m28.62s
user 14m55.28s
sys 5h58m13.24s
[EMAIL PROTECTED] #
Yes, this is a limitation of the antiquated NFS share
