Live data from Hacker News

Google loses data as lightning strikes

bbc.com

41–50 of 142 posts

Re: Google loses data as lightning strikes

#41
post #14

Earlier quoted context omitted.

The incident report ismavis posted below (and linked in the article) has far more information: https://status.cloud.google.com/incident/compute/15056#57195...

[deleted]

A proper storage array refuses to boot if the batteries are not sufficient to de-stage cache in a timely fashion, or at the very least keep cache available for the advertised (generally 72 hours) time window if it doesn't have the ability to de-stage the cache to a more permanent medium.

Re: Google loses data as lightning strikes

#43
post #33

Earlier quoted context omitted.

If you've got a way to make it easy, we'd like to hear it.

Similar to git, but if you have multiple branches of the same file, display them visually and allow the user to merge just that file?

If people have to do anything it's not good enough.

Re: Google loses data as lightning strikes

#46
I've lost attachments to old gmail messages before, I never thought it was impossible or unlikely for Google to lose data.

I'm sure the data wasn't truly lost. If I'd called them up and they'd made it their priority to find my old files, they could have done so, having so many redundant backups. But of course no one at Google is taking calls like that or acting on individual requests. The data was effectively lost, not technically lost. But I'm sure it's uncommon.

Re: Google loses data as lightning strikes

#47
post #26

Earlier quoted context omitted.

Nowadays they use Reed–Solomon coding to effectively distribute their data without copying it to 3 places.

Do you have a source for that? Why would they start using it now?

Also how would that help with geographic redundancy? Local recovery from errors does you no good if your datacenter gets wiped out in a flood.

Re: Google loses data as lightning strikes

#48

Earlier quoted context omitted.

Only because we make it hard.

If you've got a way to make it easy, we'd like to hear it.

Well image if file systems, file formats and version control systems were built from the ground up together. Currently file syncing is harder because we expect our file server to handle an infinite variety of legacy file formats and the file sever cannot try to know anything about the document structure (whereas a version control system can examine the contents of plain text files).

Surely this is why Google docs can manage collaborative working more easily -- because they can control of the whole stack.

Better than the OP would be file syncing of arbitrary files between arbitrary systems is hard.

Post reply on HN