<div dir="ltr">IIRC, Backblaze has mentioned they have a higher-level layer that distributes files and/or parity information across multiple storage pods. This is done at the application software level, well above RAID. This way, an entire pod can fail, and their service remains functional while they fix it.<br><div><br></div><div>(The par2 command is basically something like RAID5/RAID6 parity information, done at the file level rather than the device level.)</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 1, 2015 at 10:28 PM David Dickman <<a href="mailto:david@softbear.net">david@softbear.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sounds like a recipe for disaster: multiple single points of failure, all in one box. How about a second one for backup?<div><br></div><div>Found some interesting information on <a href="https://www.backblaze.com/blog/storage-pod-4-5-tweaking-a-proven-design/" target="_blank">Backblaze</a>. They appear to have a higher confidence level than I do on these. They also replace the boxes outright every three years, apparently. Their in-house configurations are 45 drives split into 3 RAID6 volumes with JFS on top. They are only using 4TB drives right now, yielding 180TB. </div><div><br></div><div>The end of the post has some interesting discussion as well. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 1, 2015 at 5:50 PM, Chris Knadle <span dir="ltr"><<a href="mailto:Chris.Knadle@coredump.us" target="_blank">Chris.Knadle@coredump.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 07/01/2015 09:35 AM, Cholewa, John wrote:<br>
> So I ordered a 36-drive, >250 TB nfs storage server for my lab. I would<br>
> have preferred avoiding needing to deal with drives that I'd normally<br>
> consider too new for use in this environment (they're 8 TB each), but<br>
> I've been limited by our heavy requirements.  The vendor is having<br>
> difficulty in getting this large amount of space to behave as a single<br>
> xfs mount point.  I may have to accept hacks along the line of splitting<br>
> up the array to multiple volumes.<br>
<br>
</span>I've been investigating hardware for a small home storage server and the<br>
8 TB drives seem worrisome to me; they're all either SMR (Shingled<br>
Magnetic Recording) drives that have some odd write timing<br>
characteristics or helium-filled drives.  Helium is such a small<br>
molecule that it slowly leaks through metal, so I have some concerns<br>
about the long-term reliability of these drives.  Because of these<br>
concerns I've decided to stick with 6 TB drives that use a more<br>
conventional design.<br>
<span><br>
> Some of the people on this list are at much larger labs, wherein pithily<br>
> small storage amounts like a mere quarter petabyte are easily laughed<br>
> off as chumpspace.  While I can't change what I'm getting here this time<br>
> around, I wouldn't mind hearing what kind of solutions are used to get<br>
> large amounts of storage to look like single mounts for end-user<br>
> researchers and the like.  Do you cluster your storage among multiple<br>
> computers and transparently make them look like a single server?  If so,<br>
> what are some good practice routes towards achieving this?  I know that<br>
> there are alternate means of doing storage over a network, so right now<br>
> I'm definitely reaching the limits of my old-school way of thinking and<br>
> wouldn't mind some pokes in the right direction.  :)<br>
<br>
</span>This does sound like you've hit the limits of a single-box solution.<br>
This probably points to needing some kind of clustering filesystem to<br>
clump together several machines like GFS2, GlusterFS, OCFS2, GPFS.<br>
[Or at least that's what I'd be researching if I was dealing with this<br>
issue myself.]<br>
<span><font color="#888888"><br>
   -- Chris<br>
<br>
--<br>
Chris Knadle<br>
<a href="mailto:Chris.Knadle@coredump.us" target="_blank">Chris.Knadle@coredump.us</a><br>
</font></span><div><div><br>
_______________________________________________<br>
Lilug mailing list<br>
<a href="mailto:Lilug@lists.lilug.org" target="_blank">Lilug@lists.lilug.org</a><br>
<a href="http://lists.lilug.org/listinfo.cgi/lilug-lilug.org" rel="noreferrer" target="_blank">http://lists.lilug.org/listinfo.cgi/lilug-lilug.org</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
Lilug mailing list<br>
<a href="mailto:Lilug@lists.lilug.org" target="_blank">Lilug@lists.lilug.org</a><br>
<a href="http://lists.lilug.org/listinfo.cgi/lilug-lilug.org" rel="noreferrer" target="_blank">http://lists.lilug.org/listinfo.cgi/lilug-lilug.org</a><br>
</blockquote></div></div>