STILL A WORK IN PROGRESS
This is still a work in progress and if you got tips or comments, let me know. I will update this blog post as I am further in my setup.
One of the downsides of using a Raspberry pi as a NAS solution is a somewhat low speed in transferring data. This is partially caused by the fact that in my previous NAS setup I'm using external USB HD's.
I came across some the cubieboard and what jumped out to me in the specs is that it has a SATA connector on the board, so I immediately wanted to give it a try.
Through ebay I bought a 'Cubieboard A10 ARM Development board luxurious package'. This kit contained a cubieboard one (developer edition), an enclosure, a 3.5" HDD addon board, a TTL to Serial cable, a breadboard with VGA connector, a uSD breakout PCB and a heatsink. I was especially interested in the 3.5" HDD addon board as I am planning to combine the cubieboard with a Seagate 2TB SSHD.
To make this whole setup work I had to buy a microSD card to host the OS and an external power adapter (Ansmann APS 1500 traveller) to supply adequate power to the cubieboard and the HD.
Hardware setup
- Seagate 2TB SSHD 3.5"
- Cubieboard mounted in its enclosure
- 3.5" HD adapter
- external power supply (providing 12V, 1500mA)
Writing a linux image to the microSD card
The microSD card came with an adapter card that could easily be plugged into my computer.
I downloaded/unpacked the Cubian image and write it to the microSD card.
I first went for the Lubuntu image, but that starts a XWindows by default, which is too much overhead for what will essentially be a headless node. Turning off the XWindows environment would be too much work so I decided to go for the Cubian image, which is a debian derivative. As the raspberry pi NAS also uses a debain flavoured distro, I think this might be the safest path to take.
I first went for the Lubuntu image, but that starts a XWindows by default, which is too much overhead for what will essentially be a headless node. Turning off the XWindows environment would be too much work so I decided to go for the Cubian image, which is a debian derivative. As the raspberry pi NAS also uses a debain flavoured distro, I think this might be the safest path to take.
Wiring up the whole things boils down to:
- plugging in the power adpater into the HDD adapter
- running an USB to barrel connector cable fro mthe HDD adpater to the cubieboard
- plugging the SATA connector in the SSHD drive
- plugging the yellow/black cable of the SATA connector into the HDD adapter board's 12V OUT connector
- plugging the SATA data cable and the 5V red/black cable into the cubieboard
- plugging in the microSD card with the freshly written Lububntu image
Configuring Cubian
Changing keyboard settings
As I'm not living in the US, the default keyboard mapping needs to be changed. I tried
sudo dpkg-reconfigure keyboard-configuration
but that didn't help changing my keymap.
sudo dpkg-reconfigure keyboard-configuration
but that didn't help changing my keymap.
sudo apt-get install console-data
If this does not automatically starts the interface for setting your keymap, execute the following.
sudo dpkg-reconfigure console-data
If this does not automatically starts the interface for setting your keymap, execute the following.
sudo dpkg-reconfigure console-data
Change the hostname:
sudo hostname cubienas
Updating the system
sudo apt-get update
sudo apt-get upgrade
Securing the cubieboard
Adjust Cubie userThe default user is 'cubie' with password 'cubie'. So that definitely needed to change to start securing the cubieboard.
Add new users
I added my own user to the system for 'day-to-day' access. This same user is used on several of my systems.
SSH access
SSH access
By default sshd is enabled but beware, cubian has sshd running on port 36000. So for logging into the cubie NAS you need to define the port:
ssh <user>@<ip address of cubieboard> -p 36000
password-less SSH access
When enforcing ssh login without providing password you need to copy your public key to the cubieboard. Unfortunately, ssh-copy-id assumes default port 22. You can circumvent this, as indicated here, like so:
ssh-copy-id-i ~/.ssh/id_rsa.pub "<user>@<ip address of cubieboard> -p 36000"
ssh <user>@<ip address of cubieboard> -p 36000
password-less SSH access
When enforcing ssh login without providing password you need to copy your public key to the cubieboard. Unfortunately, ssh-copy-id assumes default port 22. You can circumvent this, as indicated here, like so:
ssh-copy-id-i ~/.ssh/id_rsa.pub "<user>@<ip address of cubieboard> -p 36000"
Disabling ssh for cubie user
<TODOcument>
Other
<TODOcument>
Other
Other security related configurations following o.a. this blog or this blog (last one is more specific to raspberry pi, but most things can be applied to the cubieboard).
Sharing the data
Preparing the SSHDFirst thing to do is to foresee a file system for the hard drive:
sudo fdisk -l
sudo fdisk /dev/sda
sudo mkfs.ext3 /dev/sda1
Mount the hard drive
sudo mkdir /home/shares
sudo mkdir /home/shares/public
sudo cp /etc/fstab /etc/fstab.old
copy fstab file, just to be sure
sudo vi /etc/fstab
/dev/sda1 /home/shares/public ext3 defaults 0 1
sudo apt-get install samba
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.old
sudo vim /etc/samba/smb.confI had some trouble accessing my samba share but this is the current entry in smb.conf that works for me.
[DISK]
comment = disk
path = /home/shares/public
create mask = 0775
directory mask = 0775
browseable = yes
guest ok = yes
#valid users = @users
#force group = users
read only = no
public = yes
writable = yes
sudo service samba restart
restarts samba and activates the changes you added
sudo smbpasswd -a <username>
adds the day-to-day user to the samba users
I was able to mount the cubie NAS share automatically on my notebook by adding the following in /etc/fstab and running sudo mount -a afterwards:
//192.168.0.191/disk /home/someuser/central_storage/cubiedisk cifs username=sambauser,password=sambapassword 0 0
I also wanted to access the raspberry pi NAS from the cubieboard in a similar fashion to allow me to copy the content more easily. So I added the following to the cubienas' /etc/fstab:
//192.168.0.190/usb /home/someuser/central_storage/Disk1 cifs username=somePiUser,password=thePassowrd 0 0
However this did not initially work I had to install some extra software on the cubieboad to make it work:
sudo apt-get install ciffs-utils
After installing the ciffs-utils and running sudo mount -a, I had access to the raspberry pi's data.
Metrics
First test I did was copy an 734MB iso file from my notebook to both the raspberry pi nas and the cubienas.
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./cubiedisk/
real 6m31.366s
user 0m0.004s
sys 0m2.992s
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./Disk1/
real 6m29.708s
user 0m0.000s
sys 0m2.888s
cu -s 115200 -l /dev/ttyUSB0
just after booting. This showed me similar data as on the connected screen but it also showed
[ OK ] Activating lvm and md swap...done.
[....] Checking file systems...fsck from util-linux 2.20.1
/dev/sda1 contains a file system with errors, check forced.
and a progress bar showing the fsck progress.
So several cold reboots caused some errors on de file system. So I guess I will need to be patient until the fsck is finished.
I continued to check the hard drive using the SMART disk monitoring tools, following this article. These tests did not turn up any hard drive problems, so basically cold rebooting the cubieboad NAS caused the file system errors. I haven't looked at setting up SMART as a daemon, but I'll investigate it in the future to have this setup on all my machines.
The next test I performed was to start syncing again between my raspberry pi NAS and the cubieboad NAS and redirecting all output to log files on the SATA drive. If something was going to happen during sync I hoped the log files might contain some clues after I reboot the system. But actually, after a lot of big syncs the cubieboard was still up and running. So I guess the system freezes were caused by any output of the syncing not being redirected to output files.
<ToBeContinued>
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./cubiedisk/
real 6m31.366s
user 0m0.004s
sys 0m2.992s
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./Disk1/
real 6m29.708s
user 0m0.000s
sys 0m2.888s
What?! It took approx as much time to copy it to the raspberry pi NAS setup as it did to copy it to the cubieboard. The only explanation I have for this is that I'm connecting to these NAS setups via powerlan. And that might just be too slow to make a difference when transferring data.
When I'm having my laptop connected to the switch close to the NAS setups these are the results:
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./cubiedisk/
real 1m13.440s
user 0m0.020s
sys 0m4.916s
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./Disk1/
real 1m41.975s
user 0m0.036s
sys 0m3.432s
When I'm having my laptop connected to the switch close to the NAS setups these are the results:
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./cubiedisk/
real 1m13.440s
user 0m0.020s
sys 0m4.916s
$ time cp ~/Downloads/ubuntu-12.04.4-desktop-amd64.iso ./Disk1/
real 1m41.975s
user 0m0.036s
sys 0m3.432s
When doing a similar test on the NAS' themselves these are the results:
cubieNAS:
$ time cp ./ubuntu-12.04.4-desktop-amd64.iso ./copy.iso
real 0m28.707s
user 0m0.080s
sys 0m10.910s
real 0m28.707s
user 0m0.080s
sys 0m10.910s
raspberryNAS:
$ time cp ./ubuntu-12.04.4-desktop-amd64.iso ./copy.iso
real 1m38.976s
user 0m0.260s
sys 0m43.710s
real 1m38.976s
user 0m0.260s
sys 0m43.710s
Some other options to tests are:
- Newer and (hopefully) better performing powerLAN devices.
- Setup a wireless router connected to the switch next to the NAS setups.
- See if mounting the disks using NFS might be better performing than mounting them as Samba mounts
Unresponsive CubieNAS
Each attempt at synching the cubieboard overnight with my other storage ended up with an unresponsive CubiebardNAS setup. I could enter the necessary credentials for ssh, but I never get to a prompt. After a few times even booting no longer succeeds. The last message appearing on my screen is "Mali: Mali device driver loaded" and than nothing. To be sure there was nothing else happening in the back ground I connected a UDB-serial cable to the cubieboards TTL connector and executed:cu -s 115200 -l /dev/ttyUSB0
just after booting. This showed me similar data as on the connected screen but it also showed
[ OK ] Activating lvm and md swap...done.
[....] Checking file systems...fsck from util-linux 2.20.1
/dev/sda1 contains a file system with errors, check forced.
and a progress bar showing the fsck progress.
So several cold reboots caused some errors on de file system. So I guess I will need to be patient until the fsck is finished.
I continued to check the hard drive using the SMART disk monitoring tools, following this article. These tests did not turn up any hard drive problems, so basically cold rebooting the cubieboad NAS caused the file system errors. I haven't looked at setting up SMART as a daemon, but I'll investigate it in the future to have this setup on all my machines.
The next test I performed was to start syncing again between my raspberry pi NAS and the cubieboad NAS and redirecting all output to log files on the SATA drive. If something was going to happen during sync I hoped the log files might contain some clues after I reboot the system. But actually, after a lot of big syncs the cubieboard was still up and running. So I guess the system freezes were caused by any output of the syncing not being redirected to output files.
<ToBeContinued>
