In fact it’s worse now for NexentaStor: they’ve reduced the limit to 1TB now for the Developer Edition, or instead you can choose the Free Trial Edition with no capacity limits stated but you have a 30 day time-limit. As the scope of this post is for a home fileserver/NAS, NexentaStor is not suitable, as the annual ongoing costs are prohibitive — it’s meant for businesses.

Personally, I had no use for NexentaOS/NexentaCore as all that I needed was already in OpenSolaris, which is also free. Also, the APT features have now been included in OpenSolaris 2008.05, known as IPS (Image Packaging System), which you can use to download and install free security fixes. However, I believe that you have to pay for the ability to have full use of IPS for updating other packages (http://www.sun.com/service/opensolaris/index.jsp), and this appears to be an ongoing $324 payment. Again, as the scope of this post is for a home fileserver/NAS, this is unacceptable. For businesses, that may be another matter.

However, if you’re saying that NexentaCore/NexentaOS are free, have no restrictions of any sort, and allow easy updating via APT then it could be interesting.

But I do like the fact that by using the basic vanilla OpenSolaris, I know exactly what I’m using (which version etc), and can fire off questions to the great enthusiasts in Sun’s OpenSolaris ZFS forums, for example, or general driver questions, and there’s fewer external things to depend on. Anyway, for what I’ve needed here, this approach has worked fine so far.

Simon

Actually, you should be aware that the 2TB limitation is only on NexentaStor. NexentaOS and NexentaCore have no limitation on the size of any pool - they are completely open source, built on Debian and OpenSolaris. Get them from nexenta.org. The administration and reporting tools they’ve added to NexentaStor are closed source, and that’s where the 2TB limitation comes. If you already use just the command line and scripts, there would be no penalty to using NexentaOS or NexentaCore. (NexentaOS is the desktop version, NexentaCore the basic server version.) It’s supposed to run on lower-spec and a broader range of hardware.

Fantastic news. If you could send me some summary blog text, I will use it to create a new post, and will link to your article from there to give the full details that you have written.

Thanks a lot.

Simon

It is the first document on my new wiki, you can see it at http://www.genestate.com/OpenSolaris:ActiveDirectory_Integration

I would be happy to recieve any feedback people have on the guide and I will be expanding it as soon as I have some free time. It’s not really a unique guide, but it is a compilation of all the things I have found while working it out for myself

thanks,

brian

Let’s try snv_94!

Regards,
Chris

Best regards,
Chris

Cheers,
Simon

if you use CIFS as a service don’t update to snv_93!
http://www.opensolaris.org/jive/thread.jspa?threadID=65996

I haven’t tested CIFS that much, but it seems to be a big problem.
So if you not already updated to snv_93, wait for snv_94!

Regards,
Chris

Although zfs pool creation using slices is possible to do, it appears that it’s not regarded as a best practice, from what I have seen. The best practice seems to be to use complete drives. See: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

There it says:

Set up one storage pool using whole disks per system, if possible.
For production systems, consider using whole disks for storage pools rather than slices for the following reasons:

* The recovery process of replacing a failed disk is more complex when disks contain both ZFS and UFS file systems on slices.
* In general, maintaining slices increases administration time and cost. Lower your administration costs by simplifying your storage pool configuration model.

A pool created with multiple slices across disks is harder to manage than a pool created with whole disks.

> Hi JV,
> the short answer is it depends what kind of pool configuration you want. If you want
> to create a simple RAIDZ1 configuration then it’s best to have the same size drives,
> probably the same make and model too — i.e. I create a pool comprised of a single
> RAIDZ1 vdev that uses three 750 GB drives.

True.

> Or, if you had four drives, say two 500 GB drives and two 750 GB drives then you could
> create a pool composed of two mirrors, one mirror using the two 500 GB drives, and the
> other mirror composed of two 750 GB drives.

Using OpenSolaris / Solaris / SXCE / etc. you could partition the drives into 250GB chunks
and then RAID-Z2 / Mirror the pieces back together. If you do it correctly then the different
chunks on different drives / controllers will each protect one and other.

Depending on your configuration you can add the 500GB drives to the 750GB drives and then
mirror / raid them and end up with 1250GB of drive space with twice the speed (IOPS) or
take the total of (2 * (500GB + 750GB)) 2500GB and use a RAID-Z2 9+2 to get a huge MTTDL
and a lot of drive space.

Lots of ways to slice it . Partitioning improves defrag times, it is not evil.

Joel

Cheers,
Simon

Have a nice weekend!

Take care,
Chris

Simon

it’s so weird. Since a few days the bug does not appear anymore. We tried to reproduce the bug for the bugreport, but it just works. 5GB files. 16GB files. No problem at all. But I’m distrustful. Bugs like this one don’t disappear like nothing!

Would be great if you gib snv_91 a try and maybe report your experience with the release. Maybe it’s fixed already.

Chris

Simon

Chris

If you have the time and the knowledge to look at the possibility to run DTrace to see if anything can be discovered about this bug, see the last post from ‘bhorn’ here: http://www.opensolaris.org/jive/thread.jspa?threadID=59201#233503

Otherwise, I will try to debug it, but it won’t be very soon, as I have a whole load of stuff to keep me busy right now. Keep in touch!

Cheers,
Simon

I made an upgrade on my OpenSolaris 2008.05 machine. The kernel is now snv_91 and the problem is still not solved. Too bad!

Best Regards,
Chris

Al