[Tfug] NAS again
r351574nc3 at gmail.com
Mon Feb 3 08:50:28 MST 2014
I'd like to recommend the Drobo Mini.
On Sat, Feb 1, 2014 at 1:09 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> 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>
>>>>> 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
>> 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
>> 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
>> 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
>> 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
> 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
>> 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.
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
E-mail: r351574nc3 [at] gmail.com
More information about the tfug