From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Dave Taht <dave.taht@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Fwd: You're Invited: DWeb Virtual Meetup 14next Wednesday--Decentralized Storage �3D�BE �3D�BB
Date: Sat, 09 May 2020 03:34:42 -0400 [thread overview]
Message-ID: <6627.1589009682@turing-police> (raw)
In-Reply-To: <CAA93jw7ae8j5dyJLjArx4Aq6Gf3+9ZPZ5PYCjwp9A-QU3ArHFA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
On Fri, 08 May 2020 16:40:20 -0700, Dave Taht said:
> while I'm referring to stuff that's actually fun and off-topic... I've long
> off been watching progress in this area, knowing that
> "fixing bufferbloat" is a key requirement for technologies like this to
> succeed.
Amen to that. Probably around a decade ago, $DAYJOB at the time was approached
by a vendor who had a very compelling and cost-effective erasure-coded storage
product that would have allowed us to have the data at 3 sites, and total loss
of any one would be survivable. Two sites were about 3 cable miles apart, and
the third was 95 cable miles and could only run at 10Gig speed back then.
And what sank the deal was uncertainty if we could meet throughput requirements
under heavy load with one site that distant. (You'd be *amazed* what happens
in the first 3 minutes after semester add/drop goes live at midnight, when you
have 35,000 students. :)
The other great bugaboo - How do you back up a half billion files that total
12+ petabytes? (It doesn't help the solution space when the majority of it is
one research group that (a) will probably eventually data-mine their data for
$100M+ in research grants and also (b) the terms of some of the grants
specified a 30 year retention on the data *and* some wicked nasty PII issues,
because the data includes identifiable video of people who had not consented to
be part of the research study...
Storage - it turns out you can't just throw 10 terabyte drives at the problem. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-05-09 7:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4b9b07f44a3c9768397a9cb9f.1837415047.20200508232432.d498099fb3.60c67bfc@mail228.suw16.rsgsv.net>
2020-05-08 23:40 ` [Cerowrt-devel] Fwd: You're Invited: DWeb Virtual Meetup—next Wednesday--Decentralized Storage 💾 💻 Dave Taht
2020-05-09 7:34 ` Valdis Klētnieks [this message]
2020-05-09 14:48 ` [Cerowrt-devel] Fwd: You're Invited: DWeb Virtual Meetup 14next Wednesday--Decentralized Storage Ø3DÜBE Ø3DÜBB Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6627.1589009682@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox