small Fanless SBC with 2 or more SATA's I/F

Hi Folks,

I really find it difficult to stop using my old SUN station ... it works as a RAID file server without any serious problem and for years (2002 ...)

Before waiting a real catastrophic (unrecoverable) on my disks (which drive me crazy i could eat my dog ! and i don't own a dog), the noise of my SCSI disks becomes unbearable and even in a closed and ventilated cupboard. My wife shouts on me to do something rapid !

Ok i know there is some another ng for this but i'm seeking for a small and robust SBC (without a fan) with 2 or more SATA I/F.

Any advice on a rugged SBC would be welcomed.

Hab.

Reply to
Habib Bouaziz-Viallet
Loading thread data ...

Is using a USB 3.0 to SATA adapter OK? That opens up a lot of possibilities I think

--
----Android NewsGroup Reader---- 
http://usenet.sinaapp.com/
 Click to see the full signature
Reply to
bitrex

Are you using a "hardware" RAID controller? Or, doing this in software?

What sort of performance do you expect from the array? I.e., are you just using it as an archive or are you actively using it as a file store?

Been there, done that, T-shirt, etc. (I'm working on an SB2000 with two fully populated 711's, today).

By "two SATA I/F" do you mean "to support two SATA drives"? Or, "two SATA

*controllers*" (each of which might support 4 drives)?

Said another way, how many drives do you want to hang off the board/box?

I assume you're currently running Slowaris/SPARC. Are you planning on moving to Slowaris/Intel on that box? Or, turn the box into a dedicated file server (e.g., OpenFiler, NAS4Free, FreeNAS, etc.)?

[How are you planning on migrating the *content* of the array? Have you investigated the consequences of filesystem endianness?]

I've been moving my archive onto small NAS boxes (fanless Atom's) using external USB disks for the media. This allows me to power up *only* the spindles that I need as well as physically moving a spindle to another box (or even a workstation for "direct" access). Performance is far less than the FC-AL or SCA drives in the current boxes. But, I'm only using it as an archive (sort of analagous to "a trip to the library") so I can affort to wait ~1min/GB if I'm retrieving a DVD ISO (most accesses are much smaller; all are very infrequent).

Reply to
Don Y

Commodity bookshelf RAID NAS boxes seem to be the way to go these days.

--
John Larkin         Highland Technology, Inc 
picosecond timing   laser drivers and controllers 
 Click to see the full signature
Reply to
John Larkin

I have a couple of Synology DS411slim units that I like very well. They each have 4 1.5 TB Hitachi drives, and have been running flawlessly for a year or so.

I also just replaced my SoHo router/firewalls with Netgear WND3700s from eBay, with a brain transplant courtesy of OpenWRT. Seems much more robust so far.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

oh no hardware RAID controller, mdadm GNU/Linux could do the job.

good point. I'm using RAID/SUN as a file server.

I mean 4 SATA drives. I don't want any add-on PCI(e) controller. All in-board.

In my previous post i wrote 2 (or 4) I/F SATA but i realize i was confused, i want to interface 4 SATA drives with the new platform host processor.

I plan to recover my disk data through my home network and to migrate them on the new platform with NFS as it works now. No FreeNAS or something like that.

My three disks are SCSI, software RAID 1 and an archive for the third. i did not want to move any hardware things on my SUN. I could (easily?) migrate data's from my old station to my new one as i explained above.

I did not rely on any DVD media for archive nor any USB things. I prefer a hard drive for. Please could you point me an intel/atom SBC with 4 onboard SATA interfaces.

Hab.

Reply to
Habib Bouaziz-Viallet

John,

I'm not confident on so called commercial RAID NAS servers. And i did not rely on software of which I did not master myself.

Even if Phil Hobbs has pointed the DS411slim solution which is very attractive.

I want a to install myself a robust workaround for my old and venerable NFS server replacement.

Anyway thanks for the suggestion.

Hab.

Reply to
Habib Bouaziz-Viallet

Every hard drive is full of software that you didn't write. Ditto every OS.

We've dumped all our old noisy server boxes for cheap multi-terabyte RAID NAS things. We can keep a cold spare or two on the shelf, and do automatic midnight backups to a hot spare. Cheap and easy.

--
John Larkin         Highland Technology, Inc 
picosecond timing   laser drivers and controllers 
 Click to see the full signature
Reply to
John Larkin

Ah, then you're obviously *not* running Slowaris (i.e., you've repurposed the Sun box)

So, you hammer on it pretty regularly? Yet, you're still accessing it "over the wire" (or, are you using it as a workstation as well)?

OK. The Atoms I mentioned only have two SATA ports -- so they wouldn't be of much help to you.

Yet still configured in a RAID array? 2 x RAID1? Or 1xRAID10? Or RAID3/5 with or without a hot spare?

(I assume you are looking to RAID for data redundancy, not performance -- i.e.,

1 vs 0)

OK. Depending on the size of the existing drives (and the pipe connecting them), that may be a lengthy process -- just so you're aware of that.

Note FreeNAS/OpenFiler/NAS4Free/etc. are effectively the same as your "Linux" solution -- though IIRC these are all FreeBSD based (instead of Linux based). You can, for example, web administer, support ZFS, NFS, CIFS. iSCSI, etc. "out of the box" on pretty modest hardware.

I have taken the USB approach simply because it lets me decouple the physical disk from the "machine" that services it. E.g., try spinning up just *one* drive in (any of) your machine(s). Or, moving the filesystem to another machine. Or, deciding that you want to split a RAID1 across two different boxes (so, if one box dies, it doesn't risk corrupting the archive and it's mirror, on the same box!).

I.e., my new setup splits the mirrors onto different boxes and keeps a checksum (MD5) of each object on a database server. So, when I pull a file off of a volume, I get *some* reassurance that it isn't corrupt (by verifying the checksum). And, when I store a file onto a volume, it doesn't rely on a single CPU, power supply, disk controller, memory, etc. to ensure the integrity of *both* copies (because they are on different machines, entirely!).

It also is reasonably performant when configured in "full verify mode" (i.e., *which* copy of your file does your RAID array provide to you? Is it actively verifying the integrity of the mirror copy, as well?) E.g., as my approach isn't a "canned appliance", I can script each box to scan their entire complement of media, periodically, and verify their contents against the stored checksums. Instead of waiting until I *need* a particular file -- only to discover that it has been corrupted "while no one was looking".

Whatever approach you take, there will (!) be a time when you effectively have the original array *and* a new copy of it available. At that time (i.e., while you still have a means of recovering), I would strongly suggest you deliberately corrupt the new image and see what it is like to have it rebuilt. For small arrays, this is not an issue. But, for larger ones, it can be VERY painful and lead to much anxiety -- esp if the array starts throwing errors *while* rebuilding!

And, take notes -- when/if this happens down the road, you won't have the luxury of being able to "experiment"... you'll need to *know* what has to be done to recover your data before further errors manifest.

With an appliance, you're typically even more vulnerable -- as you may not be able to just pull the drives and stick them in another box when/if the appliance dies! Or, have the "other box" decide that they are "foreign drives" and promptly offer to reformat them for you! (erasing all of your data in the process)

Sorry, I have no first-hand advice, there. The boards I have just support two drives (well, I'm sure the controller supports more but there are only two connectors available on the board).

Reply to
Don Y

why not just buy a NAS appliance?

--
umop apisdn
Reply to
Jasen Betts

Drobo runs linux AIUI - you could replace the O/S.

--
umop apisdn
Reply to
Jasen Betts

This machine I use for years is for NFS file server only (and export /home to my GNU/Linux Debian stations) SUN stations i find them very reliable.

Yup, performance is not so much an issue in my case.

I don't understand "splitting RAID across ..." a single machine hosting a RAID infrastructure would be efficient, after all the RAID was designed for reliability by redundancy. Remember i have a fourth disk for archive.

[...]

Hab.

Reply to
Habib Bouaziz-Viallet

So, what you *most* want is the NFS service? Could you tolerate SMB shares? (note *which* version of NFS -- and its associated support services -- you will need)

Well, for $HOME, you are probably hammering on it more than *I* do (e.g., I can just as effectively use an FTP interface to my archives)

You are (probably) looking for a "box" that you can stuff some disks in and plug a network cable into the back side. You expect that box to run some software that mounts whatever sort of filesystem you want on those drives (NTFS, FAT*, FFS, EXTFS, etc.) and export those filesystems via NFS. At the same time, you want it (software) to maintain a mirror copy of the data that is present on "disk A" on "disk B" as well (RAID 1). And, presumably, provide some guarantees to you that the data that you are retrieving from the "disk" has not been corrupted -- seemlessly offering you the "good" mirror copy of the file, in that case (along with some sort of indication that your "original" copy is now trash and, as such, you are relying exclusively on the "backup/mirror" copy for the time being).

If, for example, that box dies, you want to be able to remove the disks and install them "somewhere" and still continue to access them -- even if only for the purpose of making a more permanent "backup" (until you can rebuild a suitable NEW "box" for them). At the same time, keenly aware that your data are no longer "protected" (if one thing fails, does that suggest another is MORE likely to do so, soon?)

In my case, "disk A" can be in one "box" (computer, memory, network) while "disk B" (the mirror half of the RAID 1 volume) is in another "box" -- in a different room, on a different electrical circuit, powered down, stored in a closet, etc. I.e., I don't have two spindles "on-line" -- unless I *need* both to be on-line.

Recall, I am using this for archival purposes, not for $HOME. So, I can afford to spin up just *one* of the two halves of the RAID 1 volume to "fetch" what I need from that portion of the archive. The only time I need both "halves" spinning at the same time is when I am WRITING to the archive -- *adding* something -- and actively making the mirror copy.

In my case, when I write something to *a* disk, the database (a third-party in this transaction) knows that "disk A" (or, disk B!) has different contents than its mirrored disk. So, *when* I spin up the other disk, I can update its contents with a copy of the data on the first disk (which has to be spinning, as well).

I.e., the mirror is not *instantly* updated as it is in your RAID 1 configuration -- where both disks are present, both spinning and *the* software that provides the interface to them, jointly, is aware of the "difference" that you've just created.

I might wait weeks to update the other half of the mirror. It may not be convenient for me to spin up the other drive *just* to ensure I have a valid mirror copy.

Imagine if I've downloaded an ISO of a new FreeBSD release. I've got that ISO on machine onto which it was originally downloaded. I've made a copy of it on my archive -- the "disk A" portion of the archive. Do I really need to update the "disk B" copy of the archive *now*? I already *have* two copies -- plus a checksum (maintained in that database) that lets me reassure myself that the copies are intact.

I can even postpone that mirroring action until AFTER I have removed the downloaded ISO from the *original* machine -- *if* I am willing to "live dangerously" (i.e., now I only have the one copy on "disk A"). OTOH, how dangerous *is* it, really? If that single copy gets munged (or, accidentally DELETED), I can always download another copy from the FreeBSD web site, etc. It's just a matter of inconvenience.

When I decide I have enough "cruft" that needs to be moved onto the mirror device ("disk B"), I power up *both* boxes and let them rsync(1) to each other. At the same time, the "new" files on each are recorded in the database -- along with their checksums/hashes.

At any time, I can verify the integrity of *either* "disk A" or "disk B" by recomputing their hashes and verifying those against the stored hashes in the database:

- are all of the files intact?

- are any files missing?

- are there any files of which the database is unaware?

As this can be a lengthy (time consuming) operation, it can be trivially made restartable/resumable -- "I have checked this disk up to THIS point. When I next have an opportunity, I will resume checking *from* that point!". Does your RAID software automatically check/scrub the entire contents of the array? Or, just when you try to *access* something?

Note that this implementation is not very high performance. But, as an *archive*/repository, it is more than adequate (if I am going to be *using* something, I pull a copy onto whatever workstation I am using and turn the archive "off" -- the little Atom boards draw so little power that I could almost leave them running 24/7 and just spin down the drives, individually, when not needed).

It also administers itself. And, lets me replace a "box" or move a "drive" without any special magic on my part. As it's an "open" implementation, I can tweak my scripts to scrub the arrays periodically, send email alerts (the boxes are all headless) of the reports (e.g., "There are N files consisting of B total bytes that are known to exist on drive 5A but for which no mirror image is available. The last synchronization event was D days ago.") provide a WWW interface for configuration *or* file access, FTP, CIFS, etc.

Reply to
Don Y

An easier way of thinking of it is:

- imagine you have a WWW/FTP site.

- you want to have a backup copy of that site, *mirrored* on another disk

- that mirror can be in the next *room*... or, in a friend's garage on the other side of town/country

Reply to
Don Y

Most (modern) NAS's run some form of FOSS -- or, software that was ultimately derived from same (e.g., perhaps the SMB service or the protocol stack, etc.).

But, few *manufacturers* support an open, documented process for replacing/upgrading the software after the sale (i.e., with anything other than their "official" releases). Often (speaking historically), there are little tweeks that tend to make "drop in replacements" impractical. E.g., I've pulled drives from working COTS NAS's that have no recognizable partition tables -- yet work. Of course, if I want to dig through *all* the sources just to discover that they've changed the MPT signature or xor'ed it's contents with

16r23, I can probably sort it out...

I have a BA NAS440 that is a reasonably nice package that runs Linux (or, maybe FreeBSD. But, the image is (modestly) mangled prior to installation -- for no reason other than obfuscation.

[I wonder if they can get around license terms by *signing* their binaries and verifying the signature in their FLASH based firmware... which need not be under GPL.. to effectively allow anyone to *see* the sources that they are using (for the *appliance*) yet not allow them to install *new* binaries -- without knowledge of the keys! I.e., "you can use our software mods -- but our hardware remains *closed* for repurposing"]

I picked up a Synology 1513+ for SWMBO (I had to get her off the old boxes and hadn't yet finished setting up my "new" file service scheme). Haven't had a chance to look under the hood to see what *it* runs. I figure I can just pull the 5x1T drives and move them to "my" system when the time comes (possibly having to offload their contents *through* the device if the FS isn't easily recognizable) and scrap the "box" they're currently in.

Sunday lunch; finestkind!

Reply to
Don Y

e

formatting link

-Lasse

Reply to
Lasse Langwadt Christensen

Just buy a NAS. No need to re-invent the wheel.

Look at the Linkstation 400 series:

formatting link

Reply to
N. Coesel

Won't support NFS so you'll have to mount $HOME as CIFS.

Reply to
Don Y

The Synology ones speak NFS. Of course NFS is horribly broken--files can disappear when you're writing to them--so I haven't used it in a decade.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

I've heard lots of complaints among Linux users re: NFS problems. But, never experienced any myself under Solaris or with any of my NFS-based appliances which typically mount an entire filesystem in place of having a local disk drive (i.e., if files/folders were disappearing, you'd expect to encounter problems *constantly* as executables, configuration files, fonts, loadable modules, etc. "disappeared").

Of course, if you run an automounter or have locking misconfigured, etc. well /caveat emptor/. Likewise if you silently run out of sockets...

OTOH, I've had all sorts of problems with CIFS requiring client or server restarts to get the service functioning, again.

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.