Linux software RAID

[Praetor]

I've got a new system on order from the 'Egg set to replace my hacked together home-server. My old system consists of 5 drives, individual partitions with a mix partitions, file system types and purposes.

This machine will primarily be used for (in no particular order)

• AV storage (entire CD collection, ripped DVDs),

• MythTV storage

• VMware Server (hey, it's free, right?)

• services: NIS CUPS, SSH, possibly FreeRADIUS and the local mail-server.

NIS and FreeRADIUS are both new to me, but I'm trying to find a way to maintain the network a bit better with consistent UIDs and permissions. Anyway.

I have 1x250g drive and 4x500g drives on order with the intention of setting the 500g as RAID5 for 1.5t of usable storage.

My initial thought was to use the 250g drive as /, /boot, /tmp and swap with /home and /media mounted on RAID. Video capture would (in theory) be done to /tmp, commercial flagged, transcoded and then moved to RAID5 when done. I'm not sure where to put the VMware images though.

From a few (1, 2, 3, 4) guides that I have found, as I understand it, the only way to have a RAID array is all-or-nothing. Is this correct?

I was thinking that my original setup would provide slightly better performance as there wouldn't be any parity checking required for the /tmp partition where I was thinking of doing the initial recording with Myth, allowing for the cpu to do other things.

For giggles, here's the specs of the upcoming system. Any advice on the above would be appreciated!

C2D E6700
Asus P5B Deluxe (6 ICH8R sata plus 2 Jmicron sata)
4G G.Skill DDR2-800
1xLite On sata dvd-rw
1xSeagate 'Cuda 7200.10 250g@7200rpm
4xSeagate 'Cuda 7200.10 500g@7200rpm

 

[nweaver]

what do you mean by "all or nothing"?

Linux software raid is incredibly flexible. You could partition those 500GB drives into 1x480GB partition and 1x20GB partition, and then set up the 480GB's into a raid5, and the 20GB's into a faster raid0 set for /tmp

/media is a generic mount location, don't mount your drives there, mount them inside of /media, such as /media/array, or /media/storage.

I have found Debian to be the easist setup for raid, as you can set it up during setup fairly easily. Defing partitions, set partitions for use in software raid, and then configure the software raid.


Prepare to go at it a few times, it took me a few tries to get everything the way I wanted it on my server. That system should do what you want pretty well I think.

 

[Praetor]

By "all or nothing" I meant it seems like you have to have the entire system on the raid, operating system and all. I was thinking I could get away with having the OS on its own drive SEPERATE from the raid to maximize storage possibilities.

Yes, /media is a generic mount location. That is where the av stuff will sit. Namely my cd collection, movie collection and transcoded myth recordings. All in a decent organized pattern.

... I've sat staring at this for about 10 minutes and I think get the point of what you're saying.

Maybe I'm too stubborn or completely missing something.


Once the array is created, I'll end up with a new raid device called /dev/md0 and I'll mount that somewhere. Either as root or under a folder in /. Which should allow me to do /, /tmp and swap on the 250g with /home, /media and probably /var on the array.

Do-able? Or a really stupid idea? I *think* I can do that, judging from the how-to's, but I'm going for real-world experience. lol

 

[Nothinman]

Yes, /media is a generic mount location. That is where the av stuff will sit. Namely my cd collection, movie collection and transcoded myth recordings. All in a decent organized pattern.

No, he means that /media is already used and should have directories below it for cdrom, usb disks, etc.

 

[Praetor]

Originally posted by: Nothinman

Yes, /media is a generic mount location. That is where the av stuff will sit. Namely my cd collection, movie collection and transcoded myth recordings. All in a decent organized pattern.

No, he means that /media is already used and should have directories below it for cdrom, usb disks, etc.

That's where /mnt comes into play. At least, that's where I've always placed my external/removable storage devices.

 

[Nothinman]

By "all or nothing" I meant it seems like you have to have the entire system on the raid, operating system and all.

Actually the opposite is true at /boot has to be on a normal, or mirrored manually I believe, device since it has to be accessible and fully readable before the RAID modules get loaded.

That's where /mnt comes into play. At least, that's where I've always placed my external/removable storage devices.

If you like, but /media is the default place for that now and things like pmount and usbmount use it by default so you might run into issues if you use a desktop environment on that machine too.

Once the array is created, I'll end up with a new raid device called /dev/md0 and I'll mount that somewhere. Either as root or under a folder in /. Which should allow me to do /, /tmp and swap on the 250g with /home, /media and probably /var on the array.

Frankly I wouldn't worry about making /tmp and /var seperate filesystems. On a home machine it's pretty pointless and the simpler the better since it makes diagnosing and fixing things easier.

Video capture would (in theory) be done to /tmp, commercial flagged, transcoded and then moved to RAID5 when done. I'm not sure where to put the VMware images though.

You might as well just capture directly to the array unless you think the performance hit during capture will make the array unusable for anything else while it's happening. Transcoding from the array to the array won't be any slower than from the other disk to the array since the transcode will be CPU bound.

I was thinking that my original setup would provide slightly better performance as there wouldn't be any parity checking required for the /tmp partition where I was thinking of doing the initial recording with Myth, allowing for the cpu to do other things.

Do you really think that a 2.6Ghz C2D will have problems keeping up with everything? The parity checking shouldn't be that big of a deal, I've got a machine doing encryption and the crypt kernel thread only uses ~15% CPU on an old 1Ghz AthlonMP and RAID5 parity has to be less work than that. Obviously it would be a good idea to do some benchmarks on your machine before you start using it but I doubt you'll run into any issues with performance.

 

[Praetor]

Originally posted by: Nothinman

By "all or nothing" I meant it seems like you have to have the entire system on the raid, operating system and all.

Actually the opposite is true at /boot has to be on a normal, or mirrored manually I believe, device since it has to be accessible and fully readable before the RAID modules get loaded.

Good point. That's partly what I was also trying to get at, in a round-about, clear-as-mud, way.

That's where /mnt comes into play. At least, that's where I've always placed my external/removable storage devices.

If you like, but /media is the default place for that now and things like pmount and usbmount use it by default so you might run into issues if you use a desktop environment on that machine too.

Ah, I wasn't aware of that. I just discovered that via Wikipedia. Perhaps keeping the that sort of thing in /usr/share/ would be a better idea?

Once the array is created, I'll end up with a new raid device called /dev/md0 and I'll mount that somewhere. Either as root or under a folder in /. Which should allow me to do /, /tmp and swap on the 250g with /home, /media and probably /var on the array.

Frankly I wouldn't worry about making /tmp and /var seperate filesystems. On a home machine it's pretty pointless and the simpler the better since it makes diagnosing and fixing things easier.

I'm using linux, why on earth would I want to make things easier? I'd like to do this as close to "the right way" as I can the first time around. I've previously kept /tmp and /var on the same partition as / without any problem, but I've seen a few people keep /var separately. I'm planning on trying to find out why that should be done in the near future.

I was thinking that my original setup would provide slightly better performance as there wouldn't be any parity checking required for the /tmp partition where I was thinking of doing the initial recording with Myth, allowing for the cpu to do other things.

Do you really think that a 2.6Ghz C2D will have problems keeping up with everything? The parity checking shouldn't be that big of a deal, I've got a machine doing encryption and the crypt kernel thread only uses ~15% CPU on an old 1Ghz AthlonMP and RAID5 parity has to be less work than that. Obviously it would be a good idea to do some benchmarks on your machine before you start using it but I doubt you'll run into any issues with performance.

No idea. This is the first time doing a raid setup of any kind. I'd prefer to ask these questions first so I get a general idea of what to expect. I'm not afraid to ask what may seem to be a silly/stupid question to someone who knows what they're doing if I don't know the answer.

Plus, this is the fastest machine by far of anything else I have running. I'm planning on using VMware or qemu to emulate other desktops and play round with configs there before I implement them in my working setup.

Thanks for the suggestions. Got any other ideas?

 

[Nothinman]

Ah, I wasn't aware of that. I just discovered that via Wikipedia. Perhaps keeping the that sort of thing in /usr/share/ would be a better idea?

Everything under /usr should be managed by the package manager. I doubt it would hurt to create /usr/share/my_crap and use that but it would be considered bad practice. Generally I use directories under /mnt like /mnt/data and /mnt/backups. Technically /mnt is supposed to be reserved for a temporary mount point for admins but nothing that I know of makes assumptions about that and I use /mnt/tmp for that.

I'm using linux, why on earth would I want to make things easier?

Because IMO using Linux does make things easier. =)

I'd like to do this as close to "the right way" as I can the first time around. I've previously kept /tmp and /var on the same partition as / without any problem, but I've seen a few people keep /var separately. I'm planning on trying to find out why that should be done in the near future.

I believe separating /tmp and /var from / is usually done to prevent you from filling up / since that used to cause problems on other unix systems. But these days a filled up / won't cause any ill affects beside not being able to put anything else on /. Now if /var/log fills up you'll lose logs and it could make it hard to figure out what's going on but the system won't die if / fills up. And since I'm assuming that you're the only user you shouldn't need to worry about malicious users filling up /tmp.

No idea. This is the first time doing a raid setup of any kind. I'd prefer to ask these questions first so I get a general idea of what to expect. I'm not afraid to ask what may seem to be a silly/stupid question to someone who knows what they're doing if I don't know the answer.

It's not a stupid question and I don't have any numbers to back it up but like I said my 1.2Ghz machine copes just fine with encrypted block devices and that has to be less CPU intensive than RAID5 parity.

Plus, this is the fastest machine by far of anything else I have running. I'm planning on using VMware or qemu to emulate other desktops and play round with configs there before I implement them in my working setup.

This should be fine too, VMWare is only CPU bound when the task running under the VM is so usually memory is more important here. I've not used qemu since the kqemu module became GPL'd so I don't know how it's performance is but I'd guess that VMWare is faster. And I don't know if it's possible to use both at the same time. I know that VMWare won't run on a Xen system but I have no idea if kqemu and the VMWare modules will fight.

 

[Praetor]

Everything under /usr should be managed by the package manager. I doubt it would hurt to create /usr/share/my_crap and use that but it would be considered bad practice. Generally I use directories under /mnt like /mnt/data and /mnt/backups.

I'm definitely going to look into this. I *liked* the idea of keeping all under /media umbrella though. lol

I'm using linux, why on earth would I want to make things easier?

Because IMO using Linux does make things easier. =)

I bought my wife a T60 a few months ago, Core Duo Yonah, IGM950-ish for video. I was all sorts of excited to throw linux on it for her, hoping to have to research random bits to get stuff running. I was noticeably crushed when I found that damn near everything worked almost right out of the gate. I had always heard that ThinkPads were linux friendly, but wow.


Anyway! Back on track. Keeping / on the seperate drive shouldn't be a problem, correct? And then creating/mounting the raid array to a location yet to be determined on / is doable and somewhat acceptable.

 

[drag]

Anyway! Back on track. Keeping / on the seperate drive shouldn't be a problem, correct? And then creating/mounting the raid array to a location yet to be determined on / is doable and somewhat acceptable.

Yeh.. If I follow you directly...

So you want to do like this:
1. Boot up your system from your one 250gig drive.
2. Setup raid array and mount it to your file system at some point.


That's great. Perfect. For something that is for high aviability you'd generally do something like setup 2 drives in a RAID1 mirror, then setup a much larger RAID5 or RAID10 (Raid10 is preferable, but more expensive. Linux has special 'RAID10' support that goes far beyond RAID1+0 or such variations, fyi.)

For for a home then that is just fine. The only trouble with booting off of a RAID5 array is that it requires a seperate /boot device (flash key is fine) and it makes things much more complicated if the RAID5 array is 'dirty'. With Linux software raid if the raid array is dirty then it probably won't boot it. The kernel will refuse to. This is because the raid array is in a unstable state and the Linux developers figure it's better to force admins to do manual commands and such to recover it instead of trying to shove all this special error-correcting code in the kernel that may end up destroying somebody's data.

So having a seperate boot/root drive is a nice way of doing things.


Probably what you'd want to do is setup a 50gig or so partition for root, that should give you lots of extra space to play around with. Then a 2-3 gig partition for swap. Then leave the rest as scratch space, maybe for mythtv read/write space or something. Or maybe a rsync mirror as a way to store important information on both that drive and the raid array decreasing the likelihood of data loss (you'd have to loose both the array AND the drive to lose that information)


For the RAID array I suggest taking a look at Logical Volumes.

The raid array will show up as a /dev/md0 device (or /dev/md1 if you have multiple arrays). This is a Physical Volume (PV).
You take that PV and add it to a Volume Group (VG). You can multiple PVs in a VG, but you only are going to have one.
Then you take that VG and divide it up into Logical Volumes (LV).

Logical volumes, from a end user point of view, are essentially partitions. But they have many advantages over partitions:
* Dynamicly resize (although Ext3 Filesystem doesn't support that)
* Dynamicly create and delete LVs with no rebooting or anything like that.
* You divide file system tasks into multiple file systems allows you to isolate problems.. ie a file system corruption is only going to affect that data instead of affecting all data.. Logical volumes make it much easier to take advantage of this.
* You can leave lots of unused space and then allocate it to different logical volumes, so as your needs change you don't end up with painfully moving data arround and trying to do dangerous partition resizes.. With LV you can do that in a online manner (except for some FSs require you have to take them offline to resize)
* you can setup LV to be block devices for emulated harddrives for Virtual Machines. Typically you use files on a file system to emulate drives as 'loopback' devices. Using real block devices for emulated harddrives have much much better I/O performance, almost as good as using real drives.
* supports some advanced features like mirroring and snapshoting.

Stuff like that.

What I do is I have a raid5 array and I boot from a flash key.

I setup a large logical volume to /share, which I use for my desktop for media files. I mirror my 'save' directory on it (and between multiple computers) That save has my important stuff so having it many multiple places protects from data loss.

I'll setup a /mythtv mount for storing mythtv files. Then I'll setup another logical volume for /var/mythtv or something (I forget the default real location) for mythtv for it's read/write buffer for doing it's time shifting stuff.

Then I'll setup logical volumes for VMs...
I'll setup Xen sometimes. I'd had as many as a dozen logical volumes used for that at one point for emulating root and swap partitiosn in the VMs.
I've exported logical volumes as iSCSI drives for running Qemu-based VMs on my desktop.

Kqemu is a accelerator for Qemu that works on all machines. For newer machines that have VT/SVM support you can use the built-in kernel's KVM support for accelerating VMs using hardware support. Pretty fast, almost as fast as native hardware.
Doing fancy stuff sometimes, like https://help.ubuntu.com/community/WindowsXPUnderQemuHowTo

Stuff like that.


Logical volumes and RAID5/RAID10 go very well together.

 

[Praetor]

Originally posted by: drag
Yeh.. If I follow you directly...

So you want to do like this:
1. Boot up your system from your one 250gig drive.
2. Setup raid array and mount it to your file system at some point.


That's great. Perfect.

Yup. Pretty much my plan.

For something that is for high aviability you'd generally do something like setup 2 drives in a RAID1 mirror, then setup a much larger RAID5 or RAID10 (Raid10 is preferable, but more expensive.

I've been reading up on that, but I think that may be a tad out of my class right now.

Probably what you'd want to do is setup a 50gig or so partition for root, that should give you lots of extra space to play around with. Then a 2-3 gig partition for swap. Then leave the rest as scratch space, maybe for mythtv read/write space or something. Or maybe a rsync mirror as a way to store important information on both that drive and the raid array decreasing the likelihood of data loss (you'd have to loose both the array AND the drive to lose that information)

Good point about the rsync. I had thought about starting that with /home. right now I do a manual "tar --create --absolute-names --preserve-permissions --totals --bizip2 --ignore-failed-read --file date.tar.bz2" of the basic install and shove it off to different pc's as backup.

For the RAID array I suggest taking a look at Logical Volumes.

Okay, I'll try to follow along. I was assuming that I would just create the array, format it with the FS of choice and create the hierarchy from there. I like your brief description of it though and what little I read in the 5 minutes I spent Googling it. Any good guides for LVM that you can think of off the top of your head? I don't want to get into a FS war, but what would be a good choice for possibly resizing a partition? I've used primarily ext3 and trying out xfs on one partition throughout my network, I don't have much experience with anything else.

What I do is I have a raid5 array and I boot from a flash key.

How is your boot time? Did you mount the key inside the case somewhere? I'm half tempted to do that now with the 8-ish available usb ports and the 2g key I've got laying around.

I setup a large logical volume to /share, which I use for my desktop for media files. I mirror my 'save' directory on it (and between multiple computers) That save has my important stuff so having it many multiple places protects from data loss.

I'm assuming that would be on your array and you're using rsync to mirror the stuff?

I'll setup a /mythtv mount for storing mythtv files. Then I'll setup another logical volume for /var/mythtv or something (I forget the default real location) for mythtv for it's read/write buffer for doing it's time shifting stuff.

Again, this would be on the array itself?

I'll setup Xen sometimes. I'd had as many as a dozen logical volumes used for that at one point for emulating root and swap partitiosn in the VMs.
I've exported logical volumes as iSCSI drives for running Qemu-based VMs on my desktop.

I like your ideas and would like to subscribe to your newsletter. lol I've been passingly following along with Xen, but I'm a bit more familiar with VMware & Qemu. The C2D has VT support, so I'm looking forward to leverage that.

Kqemu is a accelerator for Qemu that works on all machines. For newer machines that have VT/SVM support you can use the built-in kernel's KVM support for accelerating VMs using hardware support. Pretty fast, almost as fast as native hardware.
Doing fancy stuff sometimes, like <a target=_blank class=ftalternatingbarlinklarge href="https://help.ubuntu.com/community/WindowsXPUnderQemuHowTo">https://help.ubuntu.com/community/WindowsXPUnderQemuHowTo</a>

Yup. I've been using Qemu for a while now. I stopped when I made the switch to gcc4 and used the vmware player as much as I could. I just found out earlier this week that changes have been made to support gcc4 and that kqemu has been GPL'd. I'd definately prefer to go that road. Free and open source is what interests me. Which is why I primarily use linux.

I'd like to this right with as few missteps as possible. I appreciate the ideas guys!

 

[drag]

How is your boot time? Did you mount the key inside the case somewhere? I'm half tempted to do that now with the 8-ish available usb ports and the 2g key I've got laying around.

Boot time? What boot time?

I have a UPS so I don't have to worry about boot times.

But ya it's a bit slow. The slow part is when the system is booting and it's reading the kernel and initrd from the drive. Once it gets going it's fine a lot of the boot time is spent seeking between lots of small files so the slow read speeds are offset by very fast seek speeds.

USB actually kinda sucks, very flaky even on good hardware. My system apparently has very good USB support and I've been lucky that it's very stable.

This was just something I decided to try to see how well it works. If I had planned ahead for something I'd go with onboard IDE-Flash device:
http://www.logicsupply.com/product_info.php/cPath/44/products_id/512
Or a compact flash to sata/pata adapter.

I thought something like that would be very cool for a "carputer" or something like that.

I'm assuming that would be on your array and you're using rsync to mirror the stuff?

Pretty much.
It's pretty random and the directory doesn't change much so I use whatever is most convient at the time.

Again, this would be on the array itself?

Yep. My mythtv demands a pretty low. I actually don't have it setup right now (don't watch much TV anymore), but that's what I did when I was running it.

I like your ideas and would like to subscribe to your newsletter. lol I've been passingly following along with Xen, but I'm a bit more familiar with VMware & Qemu. The C2D has VT support, so I'm looking forward to leverage that.

Xen is kinda of a pain in the rear. I much prefer to use kqemu/qemu and kvm nowadays, even though Xen is faster (faster then vmware even) with Linux systems due to paravirtualization support.

Also if your setting up a bunch of servers then Vserver is very cool. Vserver isn't VM like Qemu/Vmware/Xen stuff, but it's sort of comparamentalization approach were you isolate multiple Linux systems from each other, but they all share the same running kernel. Instead of creating a virtual machine the kernel isolates systems from each other through abstractions. It's very very fast, fast as native. There are a few downsides.. like localhost doesn't work as expected so for Openssh server to work you have to tell it to listen to your network interface instead of listenning to all interfaces, otherwise it will refuse to start. Bind9 won't work, but there are patches to make it work and there are other DNS software that works well. So you see it's not 100%, but it does avoid the pitfalls with things like Xen/Vmware/accelerated Qemu.

Especially with Debian. Debian has special scripts and such that makes setting up and controlling vserver guests a breeze.(the only bug I've seen is with Unstable didn't setup the context file which causes problems starting a vserver guest after you built one. A very easy fix)



But right now my file server is down.

I had a drive fail on it. Didn't lose any information on it because of the raid5 stuff, but I am not using it until I get a replacement drive. No sense risking another drive failure on a degraded array. Luckily I just bought a new 500gig drive for my desktop so I rsync'd everything over to my desktop last night.

 

[Nothinman]

I'm definitely going to look into this. I *liked* the idea of keeping all under /media umbrella though. lol

The name is irrelevant, just use /media/mine or something and you won't have to worry about any conflicts.

Anyway! Back on track. Keeping / on the seperate drive shouldn't be a problem, correct? And then creating/mounting the raid array to a location yet to be determined on / is doable and somewhat acceptable.

You can mount your array wherever you want, personally I hate adding new directories to / but it's your machine.

 

[Uter]

Hey all, I don't want to hijack this conversation, but my situation is almost identical to Praetor, so I plan on following this closely. Having said that, I hope it's alright if I ask a question or two. I just ordered the first component for my server (Corsair 620HX PSU) and I'm thinking about using two previous drives (Seagate 7200.9 200GB and Seagate 7200.10 320GB, both PATA) in a RAID1 mirror. Eventually, I plan on building a larger SATA RAID5 array around the upcoming Hitachi Deskstar 7K1000, in a setup much like drag suggested. My motherboard will be the ASUS M2NPV-VM.

The thing is, I'm also a newb, and don't know anything about Linux software RAID. Praetor, if you don't mind me asking, which Linux distribution are you using?

 

[Praetor]

Originally posted by: drag

I have a UPS so I don't have to worry about boot times.

Cheater.

Or a compact flash to sata/pata adapter.

Like this one? Looks like some nice speeds off of that. Throw in a microdrive and you'd be set.

Yep. My mythtv demands a pretty low. I actually don't have it setup right now (don't watch much TV anymore), but that's what I did when I was running it.

I watch 3-4 shows regularly. My cable provider (who I work for) doesn't currently carry ABC-HD due to some disagreements, so I can't record Lost in HD and I'm getting tired of downloading the rips. I'd just as soon do it myself. Plus, I then burn the stuff to DVD and put it on my mom's box so she can watch the stuff she misses without cable.

But right now my file server is down.

I had a drive fail on it. Didn't lose any information on it because of the raid5 stuff, but I am not using it until I get a replacement drive.

Ouch. Were you using smartmon watch for it or was there something in your messages that warned you of an pending or immediate failure of the drive?

 

[Praetor]

You can mount your array wherever you want, personally I hate adding new directories to / but it's your machine.

I would much rather keep a consistent file-structure, but at the time it made sense to keep the media files in a /media directory.

For the moment, I think I'll just plan to keep it there until I find what the recommended structure is.

 

[Praetor]

Originally posted by: Uter
Hey all, I don't want to hijack this conversation, but my situation is almost identical to Praetor, so I plan on following this closely.

No worries.

The thing is, I'm also a newb, and don't know anything about Linux software RAID. Praetor, if you don't mind me asking, which Linux distribution are you using?

I use gentoo across most of my machines with nice, normal *recommended* cflags. I've used it for 5-6 years since I came off of a Linux From Scratch stint. I'm planning on giving Debian and CentOS a try in VM so I can understand them better and possibly switch to what people would consider a *real* server os.

 

[Uter]

Wow, and you call yourself a newb!

Haha, well to be quite honest, this looks a bit too far advanced for me. I think what I'll do, is stick my two PATA drives in an AMS Venus DS3R external enclosure, and use freeNAS for the server and boot off a USB drive. That's not a bad way to go right? Anyways, sorry for the interruption, carry on!

 

[drag]

It's not to complicated. Not realy much worse then using Linux in general, when your not used to it.

Just the terminology is a bit odd and once you get around that then it's not to bad. The most difficult part is getting the command line straight for handling logical volumes. You have things like lvcreate and such which is confusing.

Most good distros should have the ability to setup this stuff during boot-up.

For instance Debian's installer can do that and I've used it to do just that. They use a menu-based interface for configuring software raid and lvm.

Depending on everything you want to do (samba, mythtv, etc) I'd say it was moderate to moderately advanced difficulty.

But going for a distribution specificly setup for NAS work may be handy, although you'll miss out on some of the more advanced functionality.

People seem to like FreeNAS at lot, which is FreeBSD based. Then there is OpenFiler, which seems to be enterprise-geared and integrates into directory services so I suppose it's not for this sort of task.

One that I've mentioned before, but never realy used was something like http://www.clarkconnect.com/info/compare.php
They have a 'community' edition and a subscriber version. Does file sharing, email, anti-spam, firewall, etc etc etc. Designed for small business/professional home setup.

then again I am guessing that 90% of advanced NAS setups run Linux anyways.

 

[Uter]

That Clark Connect looks interesting, I'll have to take a closer look before I install freeNAS. Thanks!