The fraction of ISP customers who actually want NNTP access to local usenet servers is insignificant now - the cost of maintaing the hardware for your few customers that want it outweighs any commercial advantage of hosting it.
Usenet is becoming centralized and will no longer be usenet in the relatively near future.
Yes - that's why businesses never use network attached storage......
Does it not support hot-spares? Even with it's clever setup, having automatic rebuild eliminates risk - as soon as one drive fails you have data at risk - so you WANT a hot-spare.
I ran into a nasty boot problem with the latest official opensolaris when there were a pile of snapshots - it took a good 2 hours to boot the machine because it was doing something unnecessary regarding looking at every single snapshot and creating a vdev or something..... definitely a bug - has nexenta fixed that?
True that......
That's brilliant..... has nobody done this yet?
Works fine on all teh dell gear I've tried it on - opensolaris has been pretty good in it's latest incarnations....
After reading up, I think unRAID is great for this particular type of use - where the data isn't critical - I mean you can live without some of your consumable media - and your data loss potential is partitioned off nicely on a drive by drive basis.
Traditional raid, while simple to understand and set up is often not managed correctly - you have to have the right hot spares, you have to know what your rebuild times are, size the arrays right (right amount of parity -vs- data with relation to rebuild time) and you need to have it monitored correctly so you can act quickly when you have a mistake.
I'm seriously thinking of going out to hunt for some gear today and build a giant unRAID setup to replace my ZFS box...... I like it.
unRAID looks really interesting..... thanks!
My point was more around the setup of the RAID, and the migration to larger volumes - that's much simpler on a DROBO than with other systems like ZFS.
Also - their BeyondRaid is quite innovative - unlike the traditional RAID setups we all know, they've done it on a block by block (or at least by some allocation unit...) level - so when you pop a drive out and put in a larger one, it can restore redundancy and decide where to put things on a per-block basis. (That's probably where the apparent slowness comes from)
On a normal raid system, you can't take a 1TB drive and two 500GB drives and have it automatically set up a 1TB mirror. You would first have to create a raid-0 or JBOD of the two 500GB drives, then layer a mirror on top of that of 1TB. You also can't just decide you want to double the size of it and swap all the drives out and have it magically grow (except ZFS....).
SO yeah -drobo is good for those home users who don't want to mess around too much with raid innards and study how raid works.
Can you just yank out a 2TB drive and put in a 3TB drive (and continue one by one as the system tells you it's safe to do so) when they become available to increase your storage without downtime on those? You can on a Drobo - without resorting to any command line or configuration - just watching blinkenlights.
Obviously how? I only count 6 - though I guess if we assume the bottom of the rack(which we can't see) is identical to the one next to it, we could guess that there might be another pod under there....
Unless they changed something since they published their howto - your BZZT has it's facts wrong....
Backblaze pods use 45 drives in each pod.
Each pod is made up of 3 Raid-6 volumes.
Each Raid-6 volume is made up of 15 drives (13 drives + 2 parity)
There are two parity disks for every 13 data disks. That's higher than you might want to go in a normal enterprise setting, but as they also handle redundancy between pods, it's an acceptable tradeoff in their case that I'm sure they've calcluated out quite well given drive sizes and rebuild times and all that......
Watch the video - it's not.
Without reformatting - you can pull out the smallest drive (well really, any drive in most cases, but replacing the smallest makes the most sense) and drop in a bigger one. Then you wait for it to automatically rebuild
The drobo seems to do block-level raid - each allocation block (or whatever they happen to call it) can have it's own raid level and mirrored to a block on another block on another drive - independely, so you can migrate and raid between different sized drives with a minimum of wasted space. (It will only waste what it can't mirror somehow)
If you drop in a 1TB drive and a 500GB drive, it will give you 500GB of space. If you swap the 500GB drive with a 2TB drive, it will show you 1TB of space. If you then drop in a second 3TB in a spare slot, it will show you 3TB of space after it finishes shuffling things around - watch the demo video - it's actually quite clever and different.
Regaular old raid arrays just don't resize like that.
ZFS can with some manipulations.......
That's why you have a hotspare & an external spare to pop in when you get a drive failure - and the monitoring to back it up and fire off alarms when a drive fails - because in Raid5, as soon as one drive fails, you are exposed (and with TB SATA drives, rebuild times are long.). Raid6 is a better option - same footprint as Raid5 with a hotspare and you have some elbow room for rebuild times because you have double redundancy.
Also remember that drives bought at the same time tend to fail at the same time.
The bottom line though is - make sure you have backups of your important data - raid is not backup no matter how you slice it.
Don't panic.
