Tag Archives: Nexenta

Why large USB SATA drives suck!

For the second time in the last 6 months I’ve got forensic evidence that not only does silent data corruption happen in real life, but also that “green” drives, hidden inside external USB enclosures, seem to be at higher risk than native attached SATA. I’ve seen this with two different enclosures, with different SATA drives, connected to different servers running different OS versions.

For a while now I’ve been using ZFS, first with OpenSolaris and then with Nexenta. Recently I mirrored a significant amount of data from my internal drives on my Nexenta file server to external USB, in preparation for migrating the data to a new server with new drives at home.

My mistake was not running a ZFS scrub after mirroring the USB drives with the internal zpools.

As it turns out, there were significant numbers of files (MP3s and AVIs mostly) that were corrupt on the USB copy. How do I know? ZFS uses a checksum on every block written, and it validates that checksum on every read. There is overhead associated with this, but it’s great to know that the filesystem is protecting your data.

This is not the first time that ZFS has told me that data corruption has occurred. In both cases, the data was stored on USB connected drives, and in both cases, Western Digital “green” drives were in the external enclosure.

I don’t know if it was the USB cable, the USB-SATA Controller, or the WD Green drives that were at fault. What I do know is that those of you using non-checksumming filesystems may have data corruption on your external drives, and you won’t know it until it’s too late.

Adding AFP support to Nexenta Core 3.0

Due to the recent abandonment of OpenSolaris by Oracle, I moved my ZFS pools to a Nexenta Core 3.0 installation. In the process, I had lost the netatalk (AFP support) that I had hacked into my OpenSolaris installation.  That AFP support was done using the hints at Nathan Fielder’s blog, both for installation of netatalk on OpenSolaris, as well as making the services browseable via the Mac’s Bonjour capabilities.

I’ve done this reinstall of AFP a couple of times on a few OpenSolaris installations,  and want to make sure I have it all down in one place in case Nathan decides to erase his notes. I also want to capture a couple of other details that make Nexenta a little different than installing on OpenSolaris.

The list of tasks and commands one needs to run on a bare-metal Nexenta Core 3.0 installation differs slightly from OpenSolaris, based on the fact that Nexenta Core has fewer packages installed and fewer services enabled by default.

With appropriate homage paid to Nathan (thanks!), here’s what I did (in summary format) to get things going. I’m documenting it here so I don’t forget, should I choose to do it again on another Nexenta system. While it’s bad form, I did everything as root so you will have to insert your own escalation of privileges where necessary

Install Berkeley DB

  • Download Berkeley DB 4.8 from Oracle (be sure to look for Previous Versions, don’t struggle with the 5.x version)
  • untar the downloaded file and cd to the directory
  • cd build_unix
  • ../dist/configure –prefix=/usr/local
  • make
  • make install

Install netatalk

Add the appropriate OpenLDAP and OpenSSL development libraries so the netatalk configure script will complete correctly. Without libssl-dev, your working AFPD won’t respond to Diffie-Hillman encrypted passwords.

  • apt-get install libldap2-dev
  • apt-get install libssl-dev

Next you will need to download and untar netatalk from freshmeat. Go to the resulting folder, and make and install netatalk:

  • ./configure –without-pam
  • make
  • make install

Finally, configure netatalk (again borrowed from Nathan Fielder’s blog):

  • Edit /usr/local/etc/netatalk/afpd.conf, using the following line that enables encrypted password (that’s the “dhx” part) across all transports:
- -transall -uamlist uams_dhx.so -nosavepassword

  • Finally edit the share points. Open /usr/local/etc/netatalk/AppleVolumes.default in your favorite editor.  I have disabled home directory sharing by remarking out the line starting with ~ (please excuse the formatting and line wrap: If you copy and paste this snippet, it should properly paste as three lines of code, one is remmed out, the two others starting with “cnidscheme”)

#~ cnidscheme:dbd options:usedots,invisibledots,upriv perm:0770 /volumes/greenpool/shared “Shared” allow:bill cnidscheme:dbd options:usedots,invisibledots,upriv perm:0770 /volumes/data/tm-bill “tm-bill” allow:bill cnidscheme:dbd options:usedots,invisibledots,upriv perm:0770

Restart the service with

/etc/init.d/netatalk start

You should now be able to connect to the service via Finder, via the “Go” menu, choose “Connect to Server” and use the format “afp://servername”. Note that the username you chose to put into the AppleVolumes.default for each share must exist as a Nexenta OS user.

In a follow-on blog post, I’ll update this with the installation of DNS Service Discovery (the Open Source standard behind Apple’s Bonjour discovery service) so your other Macs can see the server in Finder. Again, that will borrow heavily from Nathan’s blog.

Comments or corrections are welcome! Comment below!

OpenSolaris is dead… what now?

OpenSolaris is dead. Well, it’s not dead, but as good-as-dead.  As announced, er, leaked in mid-August, Oracle will no longer be using the OpenSolaris community as a way to build and strengthen the core Solaris bits with help from the outside community. Rather it is taking OpenSolaris internal, and only releasing Solaris 11 binaries (as Solaris 11 Express for free use by developers).

This is one of the fallouts of M&A activity in any industry. Sometimes good products get the axe. Sometimes it’s because there’s product-line overlap and a need for consolidation. And other times it’s because the new corporation doesn’t see the benefits of a “loss leader”.  OpenSolaris was the “loss leader” for Sun, in that it attracted new users to the Solaris fold (I am one of them.)  OpenSolaris also helped Sun via a free development community, from which they could cherry-pick tried and tested code and bring it into the mainstream Solaris code base.

As a recent convert to OpenSolaris, I’m saddened that the leading-edge development of ZFS will no longer be externally available via this “reference” build. The best way to get the latest features and bug-fixes was to stay in tune with OpenSolaris.

Or at least I thought so.  Just prior to the “demise” of OpenSolaris, some important members and contributors to the OpenSolaris community split off the Illumos Project as a way to protect the Open Source components of OpenSolaris, and to continue to foster growth and innovation in what had become a stale and ignored (by Sun/Oracle) OpenSolaris project. And just in time!

The Illumos Project promises to keep alive the development of ZFS and other great features of OpenSolaris, which are very important to other projects such as Nextena Core OS and commercial derivatives such as NexentaStor, as well as the myriad of other OpenSource projects that use ZFS for volume and file management.

What will I do with my OpenSolaris, ZFS-based file server for my home use? I’m going to convert it to NexentaStor Community Edition.  I’ll be able to import my current ZFS pools directly into the new installation, the conversion will be a minimal effort. [Edited later: Since I want to install other applications, including netatalk for AFP support, I think I will actually install the Nexenta Core Platform 3.0, not NexentaStor which is an excellent appliance but locked down and not great for general purpose application use]

ZFS is a great filesystem. It’s got modest support by a couple of non-Solaris-based operating systems, but the best support is supplied by Solaris-kernel-based operating systems. Since Oracle has taken the most direct path to great ZFS support away, enthusiasts such as myself will have to turn to projects like Nexenta for our access to this great filesystem.

I’d love to hear other opinions… please leave a comment!