[CDBUG-talk] NAS hardware - MaxAttach 3000

[Mark Hutchinson]

I stumbled across FreeNAS, at http://www.freenas.org/

I'm thinking that I may see about using that on this NAS. Maxtors software
loaded on the unit creates boot swap and data partitions, then syncs the
first two over to the second drive when it's active. I'm not sure if I want
set it up like that when installing FreeNAS (to avoid having some empty
slice of disc space showing unusable, or if I want to add a CF/IDE adapter
with a 64 Meg CF card and both empty drives to mess around with this.

It looks like all the features are there, the only thing missing would be
the Error Status light, but I can live without that.

Looks like it runs on FreeBSD 6.2, I thinking that only 32Megs of RAM is the
limiter here. Anyone happen to turn up a SODIMM out of an old laptop or
something?

Mark
 

> -----Original Message-----
> From: Jaime [mailto:jaime at snowmoon.com] 
> Sent: Friday, February 15, 2008 12:24 PM
> To: Mark Hutchinson
> Cc: 'CDBUG'
> Subject: Re: [CDBUG-talk] NAS hardware - MaxAttach 3000
> 
> On Feb 10, 2008, at 10:17 PM, Mark Hutchinson wrote:
> > granite# uname -a
> > FreeBSD granite. 2.05.3075.17 FreeBSD 2.05.3075.17 #2: Thu Nov  1
> > 15:23:58
> > PST 2001     root at host26.nsgdev.com:/usr/src/sys/compile/ 
> > GRANITE.DEBUG  i386
> >
> 
> 	Wow...  A custom kernel that was compiled in 2001 for 
> an OS version that was out of date in 1997.  I'm not sure 
> what advice to give.
> 
> 
> > Would it be worth it (read: fairly easy i.e. inplace 
> upgrade) to bring 
> > it up to 3.x?
> 
> 	Actually, back then it would have been 2.0 to 2.1, then 
> 2.1 to 2.2.   
> THEN 3.0, 4.0, etc.
> 
> 	3.0 introduced some significant changes.  When I had a 
> decade less experience than I do today, I tried a 2.2.x to 
> 3.0 update and permanently killed the OS.  If you follow the 
> directions in /usr/src/ UPDATING very carefully, you might do 
> better than I did, but I wouldn't count on it.
> 
> 	It *might* be worthwhile to go to 2.1 and then 2.2 and 
> then 2.2- STABLE (which would be the most current source code 
> in that branch), but I wouldn't risk it.  Who knows what 
> customizations they put in and what you'd break....
> 
> 
> > Correct, and by more modern, I was referring to the version of 
> > FreeBSD.
> > Rather than trying to figure out what the original dev team did to 
> > support this HW and patching the flaws, I was figuring that 
> it may be 
> > faster to start with a more up-to-date version of the OS. Unless 
> > somebody has a 128 Meg SODIMM (PC100 probably) collecting dust, I 
> > guess I'd be stuck at
> > 32
> > Megs.
> 
> 
> 	I *MIGHT* have a PC100 stick around here somewhere.  No 
> idea of the size, though.
> 
> 
> >> Fortunately, even the current stable release of FreeBSD can handle 
> >> that little RAM.  It won't win any races, but it will work.
> >>
> >> http://www.freebsd.org/releases/6.3R/installation-i386.html
> >
> > I dare say if it could be done, it would work better than 
> it does now.
> >
> > I think the OS and swap partitions are 32 Megs and 10 Megs, I'm 
> > figuring that would have to change. /bin has about 24 files 
> in it, and 
> > /etc has about 60, so it's stripped down pretty far. What would a 
> > stripped down version of
> > 6.3 require?
> 
> 	I'm not sure.  My advice, if you're going to try this 
> at all, would be to use dd to backup the existing system in 
> case you want to revert it.  Then look at PicoBSD (a 
> sub-project of FreeBSD not dissimilar to  
> Damn Small Linux minus the GUI and apps) for a minimal install.   
> Otherwise, put in something like RAM x 2 for swap and at 
> least 200MB on the OS.  That should give you a tiny bit of 
> breathing room for editing configs and possibly compiling OS 
> upgrades.  Use a binary install and only put in the base OS.  
> But I've never tried anything so tight, myself.
> 
> 							Good luck,
> 							Jaime 
>