Summary: ZFSstorage 7120 : configured via shell, now GUI fails

From: Rob De Langhe <>
Date: Thu Dec 30 2010 - 08:35:25 EST
no way around restarting the array with factory-defaults. That made it
re-initialize its disks so that we can create a new pool (without logging).

The NFS-performance is still bad, tough.

With NFSv3 over 100mbps connection, a client can complete a "chown -R $uid
$dir" (where $dir contains 28000 files) only within 5-6 minutes.
Running a "du -sk $dir" takes 8 seconds, but that's only reading.

On the array itself, running exactly the same commands, completes the jobs
in less then half a second, so clearly this is purely against cache I

So wondering further what can be done to increase this NFS performance...

On Thu, 30 Dec 2010 09:41:12 +0100, Rob De Langhe
<> wrote:
> hi,
> I know, we got ourselves into a mess.
> We have this nice ZFStorage7120 box with 12 data disks (plus the default
> installed 4 log disks), and had a pool defined on it via the web
> That pool had mirrored logs over the 4 disks. Sharing a dataset from
> pool via NFS was a nightmare in terms of performance.
> We found a post on the net about heavy impact on NFS performance when
> sharing a dataset that has ZIL configured on it.
> So we wanted to trash the pool and rebuild it without ZIL logs.
> Trashing the (single) dataset was no problem, but the GUI (and the CLI)
> reported always that the zpool was still busy when we tried to trash
> too.
> So I went into the shell, and did a "zpool destroy -f" which (by magic)
> did its job.
> But now in the GUI or CLI these data disks do no longer show as
> to re-create a zpool.
> I have already rebooted the 7120 array, but that doesn't make any
> difference.
> => is there any way to make the array re-scan its disks or so, to make
> re-discover these data disks as being properly present and available to
> create pools ?
> many thx for any feedback
> Rob
> _______________________________________________
> sunmanagers mailing list
sunmanagers mailing list
Received on Thu Dec 30 08:35:42 2010

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:17 EST