?

Log in

motes of reality
to live a sweet lie or accept the bitter truth that is reality
Recent 
rebel
The Samsung drives work fine in a USB case hooked up to seijaku, but cause continuous problems (such as 'dropping off' the controller) in the Aspire. It appears that the Sunsway/ST Lab PCI SATA 2P eSATA/SATA, SiL3512 is not compatible with FreeBSD (and therefore FreeNAS). As I've also had similar problems with the on-board SATA controller in the Aspire, that must be incompatible too. This leaves me with a few options:
Use a a linux distro and manually set up all the nice bits that come standard with FN.
Get another SATA card (such as the mentioned SATA300 TX4 PCI Controller) and hope it works.
Get a few SATA-USB cases for direct storage and throw some old PATA drives into the FN server for backup.

---

Update: Borrowed another controller (SIIG SATA PCI-M) and a smaller sata drive. problem persists. Think I am going to have to go with linux and just use ext2/3 and manually set up all the niceties. An approach which has the added advantage that the drives could be mounted on OS X if needed using extsfsx.
rebel
A long weekend, and finally a chance to put those twin terabyte drives to use. Since my first attempt at getting things running gave me a little trouble, I decided to wipe the box and start over. (And document the steps this time!)

hardware
Acer Aspire E500-G870 (on-board GigE, 4x SATA II ports, VGA port, and is pretty quiet)
2x Samsung SpinPoint F1 1TB SATA2 32MB 7200RPM (for data)
2GB SSD ATA drive (for FreeNAS)

step 1 - install FreeNAS
Download and burn the LiveCD. I used version 0.69b4 i386. Since FN is an evolving project, the steps required for newer (or older) builds may differ.
Boot the PC from this and do a 'full' install.

step 2 - set up the core bits of FreeNAS
Reboot into FN.
Set up network connections at the command line and then go to the web UI on the OS X client.
Set up your System-General and System-Advanced as desired. (This is pretty straightforward - documentation is available here.)
(As I'm using gigabit ethernet, I set the MTU to 9000 to enable jumbo frames. This needs to be set on the client side too - see the notes at the end.)

step 3 - add disks
I decided to add just the first 1TB drive for testing, calling it primary, and mounting it at /mnt/pri.
Disks-Management: add the drive here (again, see the FN SUG for help).
Disks-Format: format the drive primary as UFS.
Disks-Mount Point: create a new Mount Point for primary at /mnt/pri.
(I enabled the option to run fsck at boot time.)

step 4 - add users
As I want access from my OS X user account, I need to mirror that account on FN.
Access-Users and Groups: add your OS X username/password here - for reference, I'll use sig.
Set UID to 501 and group to staff. (You can find your own values by entering 'id' at the command line on OS X.)
Tick the box to allow shell access.

step 4b - reboot FN
I found that some settings did not propagate immediately and got errors about sig being an invalid argument in later steps. Rebooting the FN server solves this (and is necessary to apply some changes from step 2 anyway).

step 5 - back to the command line
A little tinkering is required before we set up our AFP shares. Either go back to the FN server, or SSH into it. (Note that it is not recommended to share the top level of the drive through AFP, so each share should be a separate directory. This suits me as I plan to use rsync to back up, but that's for another post.)
Go to the mount point for the drive
cd /mnt/pri

Create a directory for the share and set the owner to the user set up earlier. (Apparently it is a bad idea to have the directory owned by root when using AFP if you value your data integrity.)
mkdir manga
chown -R sig manga

(Technically, the -R is only needed if there is something in the directory, so it can be omitted if you actually created the folder and didn't copy it from elsewhere.)
(If you want multiple OS X users to access the same share, you could probably have added a group in step 4 with all the users in it, and then set that as the owner here instead.)

step 6a - setting up AFP service
Go back to the web UI and enable AFP under Services-AFP-Settings.
Set a name. (I used the name of freenas box plus afp: kujira-afp.)
Tick the boxes for Enable local user authentication and Disable AFP-over-Appletalk.
Save and restart the service.

step 6b - setting up AFP shares
Go to Services-AFP Shares and create a new share with the required path e.g. /mnt/pri/manga/
Ignore the password field and enter your OS X username in the Allow and Read/Write Access fields.
Tick the 'upriv' check-box and save.

step 7 - access the share
In the Finder, open a new window. The FN server should be visible in the SHARED section on the left. More importantly, selecting it should auto-authenticate you and selecting your share should auto-mount it.
(I'm using OS X 10.5 - versions before Leopard will be slightly different, but if you've made it this far, you'll probably manage. Next time I have a guest or relative with 10.4, I'll make a note of how that works.)


notes

I mentioned setting the MTU to 9000 to allow jumbo frames. This allows larger chunks of data to pass over the network, meaning that large files need to be split into fewer pieces. To change the MTU on OS X, open System Preferences-Network, select your ethernet connection and click Advanced. Select the Ethernet tab and set the Configure drop-down to Manually. The only setting you should need to alter from default is the MTU, which should be set to Jumbo (9000).
(I seem to recall that IPv6 has an even bigger packet available, but would like to test the system in a state that I'm pretty sure should work before trying to break it all.)

In step 4, if you use the admin group instead of staff, then the user will have access to every mount point on the FN server, even if they are not configured as AFP shares! (Essentially allowing step 6b to be skipped.) I thought this might be a good idea at first, but it seems to be unsafe, and the documentation does recommend to NOT share the root level of FN drives over AFP. As I experienced problems when I tried that first time round, I avoided it on my second build and used the longer method outlined above.


to do

Install the second terabyte drive and schedule rsync to backup important shares to it from the first drive. (RAID != backup.)

Test everything for a few weeks. (Don't put data that doesn't exist elsewhere onto a test rig like this!)
2008-10-14 22:08 - there they go again...
rebel
Before I start, I have no real interest in the actual ramifications of how the DTT rollout is being handled, but lament the fact that those in authority are basically screwing up another public system because either they are incredibly short-sighted, or simply have no idea what they are doing (and worse, ignore advice given by those who do).

That said, this will probably be a long, long rant...Collapse )
2008-10-03 16:21 - run free(nas)
rebel
Decided to try ubuntu server edition given that the site lists 128MB RAM and a gig of space. After installing to a drive on an ATA-133 RAID card in the 8200, I rebooted. Into FreeNAS (the bios would not boot directly to the raid controller) -_- Forgot I had it on the 2GB SSD that I had transferred from the GL. Since it was running, I played around with it for a while...

After spending a few nights with DSL, FN is comparatively simple. A few things need multiple steps to configure, but mostly it just does what it says on the (metaphorical) box.

Firstly, a note on relevant hardware:
Dell Dimension 8200 (yeah, I know, but what else am I going to use it for) - P4 1.8GHz 256MB RDRAM
20GB drive - WDC WD204EB-71CPF0/06.04G06
NIC - D-Link DGE-528T PCI Gigabit Ethernet Adapter
I have a gigabit hub sitting on my network and want to be able to access the share from OS X, windows and linux.

FN is BSD, not linux, and its FS of choice is UFS. I could not get the main partition on the drive with the fresh ubuntu install to mount, so I just formatted the drive again. Set a mount point, turn on AFP, create a user, and the share shows up on my imac as a network location. (I could not access this before creating at a user, so it seems that AFP on FN needs at least 1 user set up.) No need to even mess around with IPs. (Note: having the FN box set for DHCP can make accessing the web gui require checking your DHCP leases.)

To test speed, I threw a few ~200 meg files across the network. Even considering the 20GB, the resulting 7-9MiB/s* seemed very low. A thread on the FN forums** led me to change a few settings. Same result.

Getting a shell on the 8200, ifconfig reported the NIC was set to 100baseTX. FN site lists the card as being supported by this driver.
ifconfig re0 media 1000baseTX mediaopt full-duplex mtu 9000
Change accepted, but still syncing at 100.
At this point, I went checking cables, only to realize that the 8200 wasn't connected to the gigabit hub at all, but to one of the ports on my ADSL router. *sigh* Never assume anything. At least I learned a few ifconfig settings in the process.

After shuffling some connections, a new test gave 20-25MiB/s. Unsure whether the new limiting factor might be the drive, I ran another search. The internal transfer rate is listed as 192-320 Mbits/s (24-40MB/s), so it seemed the results were okay.

Next steps include testing a newer drive, testing how FN upgrades, and doing another install of ubuntu server (though FN is looking like the weapon of choice).


* Having been introduced to computing in the 80s, I often use MB or megs when I mean Mebibyte and Mb when I mean Mebibit. I do try, but old habits die hardest.

** Other people don't try so hard not to use meaningless units. mb/s? >_>
2008-09-28 20:13 - NFS on DSL and OS X
rebel
Since I had DSL up and running on the GL, I figured I'd test a few things, just to get a feel for playing around with linux again. Setting up a network share was top of the list.

*As I probably wont' get time to finish this in one sitting, it should be considered a draft post, with me just collecting notes and references. Since I didn't record some things as I went, I need to run through the process again to put some things in the correct order. Anyone familiar enough with linux to be wanting to do something similar should be able to muddle through.*

While DSL comes with an NFS client, it lacks a server. Search myDSL for 'nfs' and install nfs server.

Declare the NFS 'share' by adding a line to /etc/exports
For example, to allow any user on a network to read (but not write) to the share, you would add something like
/shared_files 192.168.1.0/255.255.255.0(ro)
Or to allow read/write access from a single machine, it would be
/shared_files 192.168.1.201(rw)

To start sharing, start nfs from the DSL panel (or sudo /etc/init.d/nfs-common start) and then /etc/init.d/nfs-kernel-server start
(Note: ports should start automatically with nfs, but that may not be true on older versions of DSL.)

In theory, that's all that's required, but when I tried to access the share from OS X, I got errors like
mount_nfs: bad MNT RPC: RPC: Timed out\n
mount_nfs: can't access /mnt/share: Permission denied

There are apparently some peculiarities with the way BSD handles NFS. After a bit of forum trawling, I came up the following:

On the server, add a line to /etc/hosts for the OS X box
192.168.1.201 mac_name

In /etc/exports add the insecure option, e.g.
/shared_files 192.168.1.201(rw,insecure) 192.168.1.0/255.255.255.0(ro,insecure)

Connect from OS X using the Finder's Connect to Server menu command (cmd-K) and enter your share location:
nfs://192.168.1.200/shared_files
Or do it in a more traditional *nix fashion:
mkdir ~/shared_files
mount 192.168.1.200:/shared_files ~/shared_files

To overcome further trouble with access privileges, I changed access rights to the share on the server
chmod a+rw /shared_files
There may be a way of sync'ing account user IDs between the two, but this fix works well enough for now. There will be no 'private' data stored there, no one else using my main machine is technical enough to access the share and accidentally delete stuff, and anyone (even me) accessing from another machine will be limited to read-only access.

To Do

Read up more on options for security in hosts.allow and hosts.deny

Check out fixed auto-mounting in /etc/fstab
192.168.1.200:/shared_files /mnt/192.168.1.200/shared_files nfs defaults

Resources

Setting up an NFS Server

Putting NFS on a Debian Sarge server and client
Same goal, similar approach, different setup.

Notes on doing a Damn Small Linux install
To my knowledge, there is no (relatively) straightforward way to update the distro (as opposed to individual apps) once it's installed. Also, I find that it resets to a clean state after a reboot. I'm sure there is an option for this, but as I had shut the machine down after making the changes above, I only found out a week or so later when I got another chance to play with it.

Partial list of programs that ship with DSL and their command line equivalents

A review on DSL for the less technically minded interested in trying it out

Performance tuning

further reading
http://www.tldp.org/HOWTO/NFS-HOWTO/index.html
http://linux.die.net/man/5/nfs
http://hostlibrary.com/new-use-for-old-hardware-network-raid-backup
2008-09-28 18:08 - bits n pieces
rebel
At last a chance to sit down and type up some random thoughts and findings.

Tipping away at Go. Have about a hundred turn-based games running and managed to log into KGS earlier for a few games. Going to bribe shunming with some anime later in return for a few games. creatorofsplab is either dead or has lost the ability to text from his mobile as I've not gotten a response from him in the last fortnight.

Still haven't started on the 8200, mostly due to playing around with DSL on the GL any evening I've had an a little time to kill. (Gave up on suse since it refused to run on the onboard gfx card even though the install went fine >_<.)

Was bored some night last weekend, so started a draenei paladin with the intention of seeing how fast the slowest leveling class can progress. After tanking DM for the first time ever, I remembered why I don't like playing with people who don't listen or can't understand the concept of teamwork.

Today's random link courtesy of those crazy japanese ^^ Clear from reading a few responses that most of the posters don't mesh with the culture enough to understand why such is considered 'theft'.
2008-09-17 20:31 - run linux run
rebel
Been looking around at different distros. Will prob use Ubuntu Server for the NAS box, but am delaying setting it up until I've had a chance to play with the GL. 64 megs of RAM limit my selection to old or lite distros. Damn Small Linux seems to be one of the most recommended. Have an ISO for DeLi Linux, as well as the current vers of PuppyOS, ready to burn.

After transferring the newly purchased bits of hardware to the 8200, the GL was pretty bare, so I fitted a 4gb seagate hdd, an old ISA sound card, and a cheap 100mbps NIC. DSL recognized everything when booted from the live cd, but I hit a snag with (c/s)fdisk not seeing the seagate (or me not being awake enough when I attempted installation last night). I was going to use an old redhat 7 cd to format and partition the drive, but found suse 8 alongside it in the closet. As the requirements on the box list 64mb min for a graphic install, I figured I've give that a go, just to see what it runs (or crawls) like. Currently, it is about 45 mins through an estimated 20 min install with no end in sight -_-
2008-09-08 21:57 - no go
rebel
RAM turned up. It was ofc modern high-density stuff and the GL failed to recognize it, as did a slightly more modern doorstop I had lying around. It did work in an embedded server type box temporarily in my possession, so at least the RAM is good, but that wasn't much consolation.

The next candidate for selection is a ~1.8GHz Dell. A little overkill, but it's got a quarter gig of that damned Rambus memory, so it'll never be upgraded for anything else. With a 250W PSU, it is also quiet and has four 3.5" drive bays. I'll likely run something a bit heavier than FreeNAS on this, since it might be handy to have other services (such as a torrent client) on a machine that will be up 24/7. This may involve a bit of reading up to find something modern that will run with relatively little configuration and still have a reasonably small footprint.
rebel
Changing the plug'n'play setting in the BIOS as suggested had no impact on booting.

I hooked the 2gb drive up in another PC, grabbed the embedded version FreeNAS image, used physdiskwrite to write the img file directly to it and put it back into the GL. Same deal. Initial splash screen, then get dumped back to command line with same error. Either there is something up with a random setting or a piece of hardware, or it simply doesn't have enough RAM. Not sure how long it will take for the 64megs to arrive, or if it will work in the GL. Will consider options next week...

---edit---
Putting the 2gb SSD into another PC allowed it to boot correctly. If the RAM doesn't solve the issue, I'll probably just go with a newer machine and runs a few other things on the server too.
----------

Picked up Spore after work on friday. A good game. Haven't had a chance to do a complete run through yet, but got to the space stage in 5-6 hours. This isn't bad since I probably wasted a load if time playing with the editors ^^ Found the camera controls and behaviour to be a little clumsy compared to WoW, and the game is quite shallow in places along the way (scope for Spore II perhaps) but overall it's quite well thought out, and the learning curve is pretty steady (though I'm having a bit of trouble with terraforming atm). I imagine I'll sink several nights into replaying it once I get comfortable with the details on this first run, but the last stage is definitely the most fun. Kind of a mix of Escape Velocity, Frontier and any of the galactic-level Civ-style games you care to mention.
2008-09-05 00:12 - partial boot
rebel
FreNAS is booting to the splash screen and then dumping me back to the command line with an error something like
Manual root filesystem specification:
    <fstype>:<device>  Mount <device> using filesystem <fstype>
             e.g. ufs:/dev/da0s1a
    ?                  List valid disk boot devices
    <empty line>       Abort manual input

  mountroot>

Both the current stable 0.686.4 and the LiveCD 0.69b2 i386 beta are doing the same thing. It may be that FreeNAS really needs 96 megs of ram (only have 64 atm). Or it may be that whatever OS was installed on the 2 gig SSD previously is causing trouble. Two options before extra memory turns up:
  • Boot from another CD and reformat the 2gb drive.
  • Put the 2gb drive into another linux box and dd the embedded .img onto it.

EDIT: Removing the 2gb drive does not resolve the boot issue. Given that it boots on the PC next to me, there must be something I'm overlooking The FAQ suggests
  • Default your BIOS if you are having problems booting.
  • Disable ‘Plug and Play Aware OS’ in your BIOS, if not already disabled by default.
which I will try over the weekend, once I get some sleep. Failing that, a direct write to the 2gb as detailed here would be the next logical step.
You last refreshed motes at 2017-06-27 02:06 GMT