[Tfug] NAS again

Bexley Hall bexley401 at yahoo.com
Sat Feb 1 13:09:33 MST 2014


Hi JD,

On 2/1/2014 12:10 PM, JD Rogers wrote:
> On Sat, Feb 1, 2014 at 12:50 PM, Bexley Hall<bexley401 at yahoo.com>  wrote:
>> 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.

Yes, each of the boxes that I have (even the single spindle devices)
has provisions for USB and/or FW external devices.  I haven't used
any of these as they mean more boxes, more power cords (ever try
to find a convenient way to plug in half a dozen wall warts?  :< )
*and* I'm suspicious of how they handle insertion/removal events
(and power cycling).  Remember, the device model is "storage" so
how does it report the fact that it couldn't flush any cached data
out to that external drive that was unexpectedly removed/powered down?

>> - 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.

I'm not sure I trust the larger drives.  They feel pretty "consumerish"
(I have several 1, 1.5, 2 and 3TB external USB2/3 drives).  And, the
"high center of gravity" approach that WD uses in its products always
has me nervous that the case can topple and damage the media.  By
contrast, the NAS boxes that I have tend to be more "physically stable"
(i.e., wider than tall)

>> - 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.

Sure!  Now decide that you want ~500GB on a spindle.  How does
$200/500GB sound (i.e., if you can only get one spindle in that box
despite the fact that you *know* the hardware should be able to
support 2 or 4 easily!).

>> - 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.

So, when the disk dies (or gets corrupted), you will lose all that
functionality -- because all that cruft is undoubtedly stored *on*
the drive (hidden partition, etc.).  This was the problem I had with
the SNAPserver, originally (try locating the "reinstall image" when
the product goes out of active support).

>>    (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.

Have you tried removing the drive, yet?  :>  Remember, there are other
things that can cause the device to need service -- the board may NOT
be fried but the drive's contents might be scrambled, corrupted, lost,
accidentally deleted, overwritten, etc.  Can you rebuild a superblock?
Edit raw disk blocks, etc.?

I want to be able to pull a drive (without breaking lots of little
hidden plastic latches -- recall, I have several such external USB
drives which probably are built exactly the same way as your device),
install it in a carrier, mount it, do whatever I need to do in order
to recover it, reinstall in original box and be done.

I recently had to rebuild the image on a 2T USB drive.  It was a whole
day's worth of work!  A 500G drive pulled from a "computer" takes
an hour or so  :-/

>> - 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.

My *BSD boxes stay up for months at a time.  The only down time is
if I have to power down to move a box physically.  They don't
spontaneously stop listening to telnet connections -- yet respond to
a ping.  Or panic due to /var filling up with log files, etc.

I want "secondary (tertiary?) storage" with a very long cord.  It
should have the reliability that you expect from a disk.

The Linksys box I have won't stay up (and responsive) for more than a
day or so -- despite the fact that it can still be pinged, etc.
This doesn't leave me with a warm feeling when it comes to the data
that it's been entrusted to it!

> 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'm hoping for a different approach (keep in mind I need lots of
spindles):  find *a* system that I can reproduce reliably.  Each
of the NAS boxes that I have has a different user interface, different
configuration options, different recovery strategies, etc.  This is
too much to keep track of (e.g., I want to upgrade the 320G disk in
one of the single drive boxes to a 500G drive but dread what that will
entail -- will I have to salvage the firmware from the drive *before*
I can copy its contents onto the new drive?  Wouldn't it be so much
easier to mount the new drive in a regular system, partition the
drive as I want *there*, copy the files off the 320G drive onto this
disk, then install it in the NAS enclosure?!)

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

Power isn't particularly important to me due to the way I use the
devices:  power it up, pull off whatever files I need (or, install
whatever I want to archive), then power it off.  I.e., it draws *zero*
power 98% of the time.




More information about the tfug mailing list