Installing FreeNAS to USB Flash: Easy as 1,2,3January 21, 2009
I don’t want to get too deep into a re-hash of how to install FreeNAS onto USB flash (or “thumb”) drives – there is a wealth of community information in that regard. However, any time I come across the same simple question so many times in one week I have to investigate it more thoroughly. This week, that question has been “have you tried FreeNAS?”
Anyone familiar with the fine m0n0wall project (and off-shoot pfSense) will instantly recognize the FreeBSD appliance approach taken for FreeNAS. The look-and-feel is very M0n0wall-ish as well. In short, this is a no-nonsense and easy-to-install appliance-oriented distribution that covers the basics of network attached storage: CIFS, NFS and iSCSI. Given that M0n0wall and pfSense both virtualize very well, I have no doubt the VMware appliance version performs likewise.
1, 2, 3… NAS
That said, let’s quickly run-down a 1, 2, 3 approach for booting FreeNAS to hardware from USB drive… This is a run-from-ram-disk appliance, so the size of the USB storage device is minimal: about 50-60MB. Since I am still testing the Tyan Transport GT28 system, I will catalog my steps for that platform:
NOTE: Your BIOS must support boot-from-USB or this will not work.
- Download the AMD64 “FreeNAS Image” from FreeNAS.org;
- Insert target USB “thumb drive” into a compatible USB socket;
- If your system “auto mounts” the drive, manually unmount all partitions associated with the “thumb drive” and make note of the device (ex. /dev/sdi, so “umount /dev/sdi1″ works for my SanDisk Cruzer);
- Even though this image is a “.img” file, it is gzipped, so it needs to be extracted to your target volume:
gunzip -c <path>/FreeNAS-amd64-embedded-xxx.img | dd of=/dev/sdi
(note: my device is “/dev/sdi” – use yours from step 3)
- Eject your USB device (ex. “umount /dev/sdi”);
- Plug-in your USB device into your target platform;
- Make sure BIOS is configured for boot-from-flash (see “Preparing the BIOS” in my blog “Installing VMware ESXi on the Tyan Transport GT28” for details and screen shots);
- Boot your FreeNAS appliance;
- Configure your attached storage;
- Manage disk(s) (ex. pair of RAID1 arrays);
- Create UFS/Soft Updates filesystem volumes (one per RAID1);
- Mount filesystems;
- Create shares;
- Attach to storage via network.
Creating an iSCSI Volume for Testing
Using my two RAID1 disks provided by the LSI 1068E and four 500GB RAID-edition hard disks, I formatted two volume as UFS (GPT and Soft Updates), naming them “volume1″ and “volume2,” respectively. Next, I mounted each as “share1″ and “share2,” respectively, to provide two separate “volume containers” to house my iSCSI target extents.
To create my extents, I used the Advanced->File Editor menu to create the extents files in each share volume. Only then could I get the RAID0 device to work as an iSCSI target. While this is not a deal-breaker, this little issue could catch the uninitiated in a frustration loop…
No support (from WebGUI) exists for CHAP authentication of targets to initiators, so the IP-address block ACL is the only factor securing the use of the target. In a VMware world, this simple ACL method is probably acceptable to most, but for the security concious is may be a sticking point and may want to delve into the CLI to solve this issue.
That said, VMware ESX 3i finds the iSCSI target on the first try:
An installation of Suse Linux Enterprise Server (SLES) 10 SP2 (x86_64) went swimmingly with an average write-to-SAN rate of 8MB/sec and peaks to 20MB/sec (write). Installation was via NFS-mounted CD-ROM image so that would be a limiting factor. On boot of the VM, the SAN peaked at 60MB/sec (read) for a few seconds. Running a test using pure-ftpd on the SLES virtual server from my workstation (1Gbps) to the servers disk (a vmdk on the iSCSI SAN provided by FreeNAS) the “perceived throughput” from the ftp client was about 100MB/sec:
ftp> put w2kadv.iso local: w2kadv.iso remote: w2kadv.iso 229 Extended Passive mode OK (|||36676|) 150 Accepted data connection 100% |***************************************************| 405 MB 105.85 MB/s 00:00 ETA 226-File successfully transferred 226 3.833 seconds (measured here), 105.83 Mbytes per second 425406464 bytes sent in 00:03 (105.83 MB/s)
However, the “actual” write took much longer due to write caching from VMware:
Immediately, I was impressed with the relative ease with which FreeNAS installed on my test system. However, FreeNAS is not for everyone and, while simple and well thought-out, it has many not-ready-for-enterprise “features:”
- Change network settings = reboot;
- Add new network interface (VLAN, trunk, etc.) = reboot;
- Storage management is volume based – not partition, container or folder based (see Virutal Filesystems);
- Snapshots: No snapshots from WebGUI (can automate with a root script);
- No thin provisioning support;
- No iSCSI support for CHAP authentication from WebGUI (IP ACL’s only);
- Relatively short list of support file systems;
That said, FreeNAS works and is easy to setup and works “out of the box” with VMware ESX 3i (ESXi). The online help forum is robust and content rich and the FreeBSD is both knowledgeable and helpful. If you’re looking for a simple NAS solution without clustering or fail-over and your are already familiar with UFS filesystem management, FreeNAS will be a good fit. Likewise, if you just need a way to export a storage volume(s) in a simple and reliable way (ie. SOHO application), you might consider FreeNAS for your short list along with OpenFiler.
Given it’s lack of enterprise features (promised in upcoming version 0.7) it’s a “pass” for our Eco-System approach unless it is used as a tier-2+ storage provider. Given its simplicity, FreeBSD’s long history of reliability and security, perhaps several FreeNAS iSCSI target’s managed by an enterprise featured head-end (i.e. Nexenta) could offer an interesting combination.