[Tfug] NAS again

Sat Feb 1 12:10:10 MST 2014

On Sat, Feb 1, 2014 at 12:50 PM, Bexley Hall <bexley401 at yahoo.com> wrote:

> Hi Zack,
>
>
> On 2/1/2014 9:00 AM, Zack Williams wrote:
>
>> On Thu, Jan 30, 2014 at 4:54 PM, Bexley Hall<bexley401 at yahoo.com>  wrote:
>>
>>> So, I'm looking for an idea for *small* boxes that I can repurpose
>>> as NAS devices.  IDE or SATA are OK in the drive sizes I have in mind.
>>> I don't *need* a console -- if the box is reliable (some of that will
>>> obviously depend on my software choice).
>>>
>>
>> You might look at the "Western DIgital MyCloud" thread from a few
>> weeks back.  It's basically a hard disk enclosure that runs Debian on
>> an ARM CPU.   With aggressive disk spin down, you'd probably get close
>> to your desired power profile.
>>
>
> The problem(s) that I've found with OTS "appliances" of this sort are:
> - single spindle (means each spindle needs a network drop)
>

FYI, the MyCloud has 1 USB2 and 1 USB3 port and support dropping additional
storage on them. (I read that the USB 3 actually is limited to the same
speed as the USB2 interface because of CPU limitations, but I haven't
tested). So if speed is not a big deal, the MyCloud could be the network
interface to 3 drives this way. Not as flexible as what you may want, but
it does make for some interesting solutions.

> - current "with disk" offerings are too big (this is my "precious"
>   archive -- i.e., nothing can get lost -- so I distrust few/big
>   spindles)
>

For my purposes, the 4TB drive with a couple of other TB drives for
mirroring is a pretty good option. This way I have everything in 3 places:
one drive off site in case of flood / fire etc, and duplicate on two big
drives in the house.

> - cost (some of the "no media" boxes are as expensive as a PC)
>

$219 for 4TB drive with arm proc, 2 USB ports, and gigabit ethernet. I felt
like that was a pretty good price point.

> - bloated implementations like to store *their* firmware on the medium
>

As far as I can tell, this is debian. You can remove packages, install
whatever your want to your heart's content. There are some limits on ARM vs
a heavier duty x86 proc, but that comes with power costs.

>   (such a device needn't be more complicated than an SoC implementation;
>   the fact that many want to overkill with a Linux/BSD-based design
>   shouldn't mean *I* have to worry that the disk failing takes the
>   firmware out with it!)
> - proprietary implementations (I can't just remove the disk and recover
>   its contents using a *better* set of tools than the tools made
>   available with the appliance)
>

Not sure, but I would imagine that if the board fried and I wanted to yank
the drive, it would be SATA. I can't imagine they would use something
proprietary and still keep the cost this low. Economy of scale and all that.

> - disk cycling (just leave the damn disk spinning; I'll UNPLUG the
>   box in the next hour and save far more power/wear-and-tear than
>   your efforts ever could!)
> - media limitations (ancient 24b IDE controllers/127GB limit)
> - systems that become unresponsive over time (memory leak?  thermal
>   problem?  buggy software??)
>

I agree with this one --  I have seen a couple of hangs already. There was
an update with a changelog that sounded like it may have been fixed, but
we'll see. In any case, since this is debian, the sort of hangs are either
due to something that I would also have to deal with on box I build myself,
or they are due to the extra functions built in to the install. If that is
the case, you can always remove those bits easily enough. I may do that,
but I haven't yet as I wanted to see if I liked these extras.

I am sure there are things not to like, but for the price I have been
pleased. I have depressingly little time to tinker and admin boxes these
days, so I was willing to just make use of something where everything was
firmware and resign myself to being a user, but I was very pleasantly
surprised when I found out the thing runs debian and is basically just a
really tiny low power system. Pretty neat for my purposes.

I can even try a power meter and report back power usage if you are
interested in numbers.

>
> Performance has seldom been an issue for me.  I'm using these as true
> archives -- not "online storage".  So, I might pull down a ~300-500MB
> CD ISO if I need to install the software on that ISO... then, discard
> the downloaded image.  Or, grab a handful of technical papers and
> pull them onto my local workstation where I can reference them for
> days or weeks at a time (the archive needn't be spinning while I'm
> doing that!)
>
>
>  If you need an x86 CPU for some reason, you might look at Atom or
>> similar low power boards, but I tend to find that the best
>> price/capacity sweet spot is the Gen7 (AMD CPU) HP Microserver.  It's
>> much more involved than you describe (4x 3.5" bays), but still very
>> quiet/power efficient.
>>
>
> The HP devices seem designed to handle a much heavier load (traffic)
> than I'd ever need (unless I was copying one archive to another).
> And, they come with a corresponding price tag (several hundred bucks
> before you add media; if you are opting for small spindles as I am,
> that starts to look really pricey!)
>
> I'm not wed to any particular hardware implementation.  But, ISTM
> that a "small PC" is the most practical alternative.  The trick is
> finding one that is "mis-optimized"... enough drive bays to avoid
> the "one spindle per NIC" issue yet not bloated with lots of MIPS
> (which translates into power and cooling requirements).
>
> E.g., this is similar to how MS (and now Intel/AMD) found itself screwed
> as the market shifted from bigger and faster workstations (that could
> run increasingly bloated software with silly features) to handheld
> devices that are (comparatively) resource starved and not willing to
> pay for those features (size, battery life, performance, etc.)
>
> I was told to look at "Shuttles" (?) in that they are a very small
> form factor and could probably accommodate 2-3 drives (haven't done
> that research yet)
>
> Thx,
> --don
>
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20140201/1c084b66/attachment-0002.html>