ZFS scrub operations operate on some fairly brain-dead principles. Most notably, it only spends time scrubbing when there's nothing else going on. If you poke a pool with just a bit of data access on a fairly constant basis, scrub will effectively starve itself and do nearly nothing.
Tunables to explore, with my quick notes on what it does (I last looked ...
Is it strongly recommended to avoid using RDM's for this purpose.
Pass your SATA controller through to the virtualized NexentaStor instance using "PCI Passthrough". This requires a reasonably-current processor to do so.
See: Hosting a ZFS server as a virtual guest
That said, there's no major issue running ZFS on VMDK's if you have an underlying hardware ...
Please see the notes about configuring an all-in-one ZFS setup in my post at: Hosting a ZFS server as a virtual guest.
If you're talking about creating an SSD pool or adding drives as raw device-mappings (RDM's), disregard the rest of this answer. The preference there would be to run through the HBA versus RDM. Use SAS expanders if needed. The main reasons ...
As mentioned, you cannot "upgrade" the OS portion of the system. You can however, export your existing data zpool (tank), install Solaris on the OS disks and re-import them without any trouble.
Things that may not survive are iSCSI configurations, but if you're just using it as an NFS NAS, that configuration information is contained in the zfs filesystems. ...
As a long time user of Sun/Oracle ZFS 7000-series appliances, I can tell you without question dedupe isn't polished. Never confuse sales with delivery! The salesguys will tell you "Oh, it's been fixed". In real life - my real life - I can tell you 24GB isn't enough to handle the "DDT tables". That is, the back end index which stores the dedupe table. That ...
8Gb Fibre Channel
Enabling compression on your ZFS zvols/LUNs.
Who is consuming this data? Are you actually seeing bottlenecks?
And remember, it's not always about throughput. Have you taken time to understand your I/O patterns? The mix of read to write? The nature of the transfers?
Can you give more information about the setup?
I'd suggest dedicated drives for OS and dedicated disks for data. NexentaStor is software RAID and the loss of an OS disk can be painful. You can combine L2ARC and ZIL, but the class of SSDs you're probably using won't be helpful as ZIL devices.
I understand the desire to try to use all of these ZFS features, but you really have to do it the right way. I ...
Oh my god... what did you do?!?
In general, RAIDZ1/2/3 will show zpool listings with the full (raw) capacity of the drives, while zfs listings will show the space minus parity...
But what you've shown above is:
A 9-disk RAIDZ1 striped with a 3-disk RAIDZ1 and a 6-disk RAIDZ1.
That's pretty bad if you weren't intending to do that. Are all of the drives ...
Here's an example (albeit from 2008) of how one might use zdb/mdb to find the older uberblock and recover the orphaned file. Probably not too practical for single file undelete, but I had an unmountable raidz pool which was mostly recoverable after winding back past a dozen corrupt uberblocks. Given infinite time I don't think I could've ever done it, but ...
Start again and RAID1 your 3TB disks. Performance will suffer in that you can't split between spindles, but you really do not want your VMDK's on non-RAID disks.
If you do as you suggest, then your 2x 400GB disks will be fault tolerant, but the system that serves that data will not be. So you're not going to prevent any downtime - and as we all know, RAID ...
I'd start by comparing the LMCompatiblityLevel setting between the non-working and working machines. I'm getting a feeling that something is fishy with NTLM protocol negotiation between the client and server.
If you can, get a packet capture of the traffic between the client and server for each attempt you described. There's nothing like actually seeing ...
I probably should start with "ZIL is not write cache". It's the ZFS Intent Log for Synchronous write requests, which means it's only used in certain circumstances (mainly for synchronous writes) and only improves speed in those situations when the write to the actual storage array would take longer than writing to the ZIL, and it doesn't actually write any ...
Your write cache (ZIL) does not need to be large. Sizing is really a function of your anticipated write rate to the array.
Think about the purpose of the ZIL... to absorb random writes to low-latency storage and coalesce them to flush sequentially to the disk pool. In Nexenta, you basically need a ZIL large enough to handle up-to 30 seconds worth of writes....
What you are looking for is the l2arc_write_max, not l2arc_max_write; same for the boost setting. SSH paste from a Nexenta box:
root@lead:/export/home/admin# echo l2arc_write_max/D | mdb -k
root@lead:/export/home/admin# echo l2arc_write_boost/D | mdb -k
I suspect hardware...
Why would you let this run for 15 days? That's not normal. Stop the scrub - zpool scrub -s tank and check the system out.
Which controllers are you using?
Is this the first scrub you've ever run on this pool?
Was there a problem that prompted you to run the scrub in the first place?
The slice visibility occurs during the resilvering operation. When it's complete, the normal device names are usually restored.
As for your zpool replace operation, you only needed to use the device name. Not the full path.
(by the way, that's a crazy-large raidz2 pool!!)
Yes it is possible, you just need to set up the port as a "trunk port". You can also add ACLs to permit only those two VLANs.
You will also need to set up appropriate VLANs on your ESXi (In the virtual switch configuration, you'll have to set up VLANs for your virtual machines, for all of them to be in the "lan" VLAN).
Don't use NexentaStor for new installations in 2015. It's a dead product!!
You could post a support question on their forums (good luck), but the community user base was basically abandoned and there are simply better alternatives for a ZFS storage appliance. The main reason to consider this advice is hardware support. Linux and other actively-developed ...
1) Disconnect all writers and try to reboot your host, it should fix the issue.
2) Contact Nexenta for support you already paid for. Alternatively you can migrate to FreeBSD and keep all of your ZFS volumes: FreeBSD has much bigger community compared to Nexenta.
The answer is NO, kinda... But probably no in your situation.
I use LACP (with a switch) over 10GbE ethernet to my NexentaStor storage servers... but that's something that is only possible via VMware 5.1 and through the use of distributed vSwitches. That's a feature only available at the vSphere Enterprise Plus license tier.
What I do in situations where ...
I opened a support ticket with Nexenta to try to get an official answer since I tried to search through the UI and configuration files for a tunable...
Currently there is no way of increasing the timeouts for the analytics
in the current version. This will be rectified in a future version.
I believe this has to do with the Solaris kernel version and patchset that is on NexentaStor 3.x (I don't think you'll see this on 4.x+ once it is released, though don't quote me - I think it still says it, but then boots anyway).
I've had a heck of a time keeping KVM VM's of NexentaStor stable, it isn't presently supported on the 3.x line by Nexenta ...
Questions like firewalls are good things to check. Once you are sure the machines can talk to eachother, I found that I needed to set some access control in ZFS:
zfs set share=name=tank,path=/tank,prot=nfs,nosuid=true,sec=sys,email@example.com/24,firstname.lastname@example.org/24 tank
Try that and see if you can get them talking.
Given that Nexenta was OpenSolaris-based at that time, you may be running into this issue. It does seem like file descriptor limits aren't being applied in a consistent manner throughout the system.
Are you actually using hosts.allow/deny in your setup?
What does lsof output look like?
If you want fault tolerance and the ability to recover from corruption, then you need two different things.
You should use RAID, first of all. I'd recommend RAIDing the two disks and presenting it as one datastore. If you can't for some reason, then you shouldn't use this box to present storage to the VMs. If you still must, then use software RAID inside of ...
VMware article on debugging "Failed to ack TLB" purple screens:
It sounds like hardware, you may need a VMware tech to investigate.
Why is there a problem with having one NexentaStor port in the storage vlan and one in the normal data network vlan? That is a perfectly-valid setup.
For a two-port Nexenta system, I'd probably plan on acquiring another 2 or 4-port network card...
But if you're stuck with what you have, you can simply get away with creating two vlans on your ProCurve 1800 ...
Honestly, using VST for the sole purpose of having access to the WebUI on the Nexentastor isn't the right way to go about this, IMO. You're adding unneccessary complexity for no real benefit. If your desire is to be able to access the WebUI of the Nexentastor you should be able to easily do that via the iSCSI network from a dual-homed management station. ...