On 10/25/2013 11:33, Lists wrote: > > I'm just trying to find the best tool for the job. Try everything. Seriously. You won't know what you like, and what works *for you* until you have some experience. Buy a Drobo for the home, replace one of your old file servers with a FreeBSD ZFS box, enable LVM on the next Linux workstation. > That may well end up being Drobo! Drobos are no panacea, either. Years ago, my Drobo FS would disappear from the network occasionally, and have to be rebooted. (This seems to be fixed now.) My boss's first-generation Drobo killed itself in a power outage. It was directly attached to his Windows box, and on restart, chkdsk couldn't find a filesystem at all. A data recovery program was able to pull files back off the disk, though, so it's not like the unit was actually dead. It just managed to corrupt the NTFS data structures thoroughly, despite the fact that it's supposed to be a redundant filesystem. It implies Drobo isn't using a battery-backed RAM cache, for their low-end units at least. Every Drobo I've ever used[*] has been much slower than a comparably-priced "dumb" RAID. The first Drobos would benchmark at about 20 MByte/sec when populated by disks capable of 100 MByte/sec raw. The two subsequent Drobo generations were touted as faster, but I don't think I ever hit even 30 MByte/sec. Data migration after replacing a disk is also uncomfortably slow. The fastest I've ever seen a disk replacement take is about a day. As disks have gotten bigger, my existing Drobos haven't gotten faster, so now migration might take a week! It's for this single reason that I now refuse to use single-disk redundancy with Drobos. The window without protection is just too big now. A lot of this is doubtless down to the small embedded processor in these things. ZFS on a "real" computer is simply in a different class. [*] I haven't yet used a Thunderbolt or "B" series professional version. It is possible they're running at native disk speeds. But then, they're even more expensive.