FreeNAS 0.68

March 6th, 2007 | by jg3 |

These are my notes on my NAS, your mileage may vary.

1 ea. Adaptec 2610SA 6 port SATA RAID card
6 ea. Samsung HD501LJ SATA-II drives
1 ea. Old PC (AMD 1200 + SOYO SY-K7VTA PRO motherboard, could probably use a NIC upgrade)
w/ CD-ROM drive
w/ Floppy drive
1 ea. image of the latest FreeNAS

The disks are “500 GB” but only format out to be 465.5 GB (93% of 500 GB). Let me just take a second to say: it was more or less okay when 1000 bytes were called a kilobyte (which is actually 1024 bytes, so that was 97% correct), but now we’re edging toward ten percent disparity between what is advertised and what exists. At some point this has got to stop.

There are a few different RAID options here, the leading options being RAID 50 and RAID 5 with a hot-spare disk. My primary concern is efficient use of the available storage space which leads me to the RAID 5 + 1 hot spare solution. The efficiency there if you include space wasted on the hot spare disk is 66%. A RAID 50 layout only gives me 66% efficiency and all drives are in use. In theory, I could drop from “hot spare” to just “spare” and create a non-redundant volume on the extra disk. Why not just build a 6 disk RAID 5 array? Good question. Because the Adaptec 2610SA only gives me the option for RAID 10 or RAID 50 when I select all six drives.

When I first connected the card I kept getting “Error Code: 63″ but I switched to a different PCI port and that error stopped. I can’t find any on that, but that’s hardly suprising. Adaptec does not acknowledge the existence of the 2610, they were only produced as OEM for Dell and HP. That’s probably the reason you can find them for around $100 right now. Oh, you might note that the SOYO SY-K7VTA PRO only has 32 bit PCI slots and the card works. I know I’m not getting full speed out of the card, but even in a 64 bit PCI slot I wouldn’t get all 300 MB/s out of these SATA-II disks anyway. Oh well.

Once I saw that supported the Adaptec 2410 (the driver manual even expicitly lists the 2610SA) and since FreeNAS is based on 6.2-something I was reasonably sure I’d have no trouble. That turns out to be correct.

Not only is the build/verify process really freakin’ slow (I’m not sure how long I expect it should take brand spankin’ new drives to organize into a 1862 GB array, but it isn’t done yet), I kept restarting it after reading more about RAID levels and stripe sizes. Once that completes I’d like to do some benchmarks and maybe rebuild it with a different stripe size. Maybe I’ll have the patience for that, maybe not. Ideally I could test 64K, 128K, 256K (default), and possibly 1024K. I’m not that much of a tweaker, and the bottom line is that the 266 MHz FSB and 10 base-T NIC are probably the limiting factors, anyway.

–
Update: I replaced the NIC with a 10/100 Intel that runs on the fxp driver. I was able to write to the NAS at wire speed with no overrun/underrun errors. So there’s the performance bottleneck in this system.

Filed under: ,

Related stuff

  1. One Response to “FreeNAS 0.68”

  2. By Zephyrr on Jan 13, 2008 | Reply

    Thanks for sharing your experience with the NAS.

    As for the GB vs GiB confusion, I think the only sustainable answer is in the other direction - consistently using metric prefixes for powers of 1000, and binary prefixes (Kibo, Mebo, Gibo,Tebo) for powers of 1024. Then rethink - when are binary prefixes really meaningful? The answer is: only for some solid state memories (RAM, Flash) that are inherently addressed by an integer number of binary address bits. IDE and SATA and ethernet use metric units. Disk drives (hard and CD/DVD) use metric units. Your data files (a word document, a jpeg, an executable image) do not come in binary powers like RAM, there is no reason to confuse anybody with powers of 1024.

    The 500 GB (500,000,000,000 approx) is not marketing hype - it’s the official standard way to describe disk drive sizes for consistency, just as gigabit ethernet means 1,000,000,000 bits per second not 7% higher than that.

    The root problem is that OS vendors carried forward the programmer orientation of using 1024 units since the days when even a supercomputer still measured its core memory in “Kilowords”. There’s no reason a file size needs to be described to a user in anything other than metric sizes; nobody but us programmers needs to be aware of what that translates into in hexadecimal - or 1024 powers.

    The OS vendors need to start reporting metric sizes in all cases UNLESS a programmer has reason to configure it otherwise - and even programmers will very, very rarely use such an option. Like a kernel hacker trying to see if a memory mapped file will just barely fit into one page or overflow into two. The rule of thumb is: unless you are counting bits that something will take to represent, always use decimal powers.

    Anyway, thanks again for your page (and for listening). Zeph

You must be logged in to post a comment.