Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

S3 is files, but not a filesystem

calpaterson.com

Post reply on HN
Print view View original

431–440 of 456 posts

Re: S3 is files, but not a filesystem

#431

Post by Kluggy »

tom910 wrote: post #415
bigiain wrote: post #348

Earlier quoted context omitted.

At least 3, in at least 3 seperate datacenters. According to https://nuclearsecrecy.com/nukemap/ - it'd take at least a 1 megaton warhead to take out two of the ap-southeast-2 datacenters, and over 10MT to take out 3. I suspect you'd need a lot less than that though, the 1MT warhead would probably take out enough outside-the-datacenter infrastructure to take the entire AZ offline. I don't care too much though, if som…

I think lees. Why AWS need to store 3 times if they can use Reed-Solomon algorithms (or similar) and decrease this number to 2 or 1.5 and save a lot of storage space

Reed-Solomon would allow you to lose any one of the three and recover. Losing two would be catastrophic.

AWS's guarantee is that you can lose two of the three copies and still have all the data. You can't do that without three complete copies.

Re: S3 is files, but not a filesystem

#432

Post by snotrockets »

Very mild take: S3 is a very reliable, relatively cheap, high latency, key-value store.

The reason I don't think about flies on a UNIX-derived systems as a key-value store (filename->file content), is that in such systems, we have many things that aren't really files that expose a file system interface regardless.

Re: S3 is files, but not a filesystem

#433

Post by jameshart »

orf wrote: post #428
jameshart wrote: post #399

Earlier quoted context omitted.

Two. The one to set up the lifecycle rule. Then the one to delete the bucket, some number of hours later.

Incorrect. One call to trigger a step function that sets up the lifecycle rule, sleeps for 24 hours and then deletes the bucket. Stop being silly, as if 1 vs 2 API calls matters. You should empty large buckets with lifecycle policies. It's trivial.

Imagine for a second you’re a Unix user, familiar with the rm command.

Imagine you are using windows for the first time and you want to delete a directory, so you find an answer on Serverfault that explains that to do so you need to spin up a COM object that marks the directory for deletion, then the next day comes back and deletes it.

You might be inclined to say ‘that seems overly complicated’.

The original answerer is confused though. ‘It’s trivial, stop being silly. Can you think of a simpler way to delete a directory?’

Do you see now why I thought the ‘non triviality’ of deleting an S3 bucket was perhaps relevant in a discussion on an article about why S3 is both simpler and more complex than a file system?

And why your approach might not actually be making the case for it being as simple as you think?

Re: S3 is files, but not a filesystem

#434

Post by mistrial9 »

anonymous-panda wrote: post #259
catlifeonmars wrote: post #235

Earlier quoted context omitted.

S3 is fundamentally a key value store. The fact that you can view objects in “directories” is nothing more than a prefix filter. It is not a file system and has no concept of directories.

Directories make up a hierarchical filesystem, but it’s not a necessary condition. A filesystem at its core is just a way of organizing files. If you’re storing and organizing files in s3 then it’s a filesystem for you. Saying it’s “fundamentally a key value store” like it’s something different is confusing because a filesystem is just a key value store of path to contents of file. Indeed there’s every reason to beli…

no - a filesystem implementation on an ordinary OS has more than what you mention, including interfaces to disk device drivers

Re: S3 is files, but not a filesystem

#435

Post by benlivengood »

catlifeonmars wrote: post #233
supriyo-biswas wrote: post #196

Earlier quoted context omitted.

Checksumming the data is not based out of paranoia but simply as a result of having to detect which blocks are unusable in order to run the Reed-Solomon algorithm. I'd also assume that a sufficient number of these corruption events are used as a signal to "heal" the system by migrating the individual data blocks onto different machines. Overall, I'd say the things that you mentioned are pretty typical of a storage sy…

The S3 checksum feature applies to the objects, so that’s entirely orthogonal to erasure codes. Unless you know something I don’t and SHA256 has commutative properties. You’d still need to compute the object hash independent of any blocks. Source: https://docs.aws.amazon.com/AmazonS3/latest/userguide/checki...

It's not entirely orthogonal; RAID5 plus stripe-level CRC (or better) can reliably correct bitrot at any single position in a stripe whereas RAID5 alone can only report an error. My guess is that S3 and other large object stores have the equivalent of stripe-level checksums for this purpose.

Re: S3 is files, but not a filesystem

#436

Post by orf »

jameshart wrote: post #433
orf wrote: post #428

Earlier quoted context omitted.

Incorrect. One call to trigger a step function that sets up the lifecycle rule, sleeps for 24 hours and then deletes the bucket. Stop being silly, as if 1 vs 2 API calls matters. You should empty large buckets with lifecycle policies. It's trivial.

Imagine for a second you’re a Unix user, familiar with the rm command. Imagine you are using windows for the first time and you want to delete a directory, so you find an answer on Serverfault that explains that to do so you need to spin up a COM object that marks the directory for deletion, then the next day comes back and deletes it. You might be inclined to say ‘that seems overly complicated’. The original answere…

Right click, move to recycle bin, wait for the progress bar to finish. Except the progress bar takes a day or so.

This is only needed if you have a huge (100 million+) bucket, at which point you should be experienced with s3, otherwise you can just click the big, clear and obvious “empty bucket” button on the console.

Re: S3 is files, but not a filesystem

#437

Post by [deleted] »

kiwijamo wrote: post #290
ForHackernews wrote: post #96

Earlier quoted context omitted.

This is not true in my experience https://www.backblaze.com/cloud-storage/pricing

That Backblaze page (not surprisingly) compares their prices to a fairly expensive S3 pricing tier and makes other assumptions in Blackblaze's favour. For some use cases B2 is more expensive e.g. one copy of my backups goes to AWS Deep Glacier which is really cheap.

[deleted]

Re: S3 is files, but not a filesystem

#438

Post by flybarrel »

bigiain wrote: post #348
cyberax wrote: post #335

Earlier quoted context omitted.

At least 3.

At least 3, in at least 3 seperate datacenters. According to https://nuclearsecrecy.com/nukemap/ - it'd take at least a 1 megaton warhead to take out two of the ap-southeast-2 datacenters, and over 10MT to take out 3. I suspect you'd need a lot less than that though, the 1MT warhead would probably take out enough outside-the-datacenter infrastructure to take the entire AZ offline. I don't care too much though, if som…

1MT will take out the infrastructure to make the data not Available. However the data is still in the 3rd datacenter, making it still accessible therefore no compromising on Durable but yes we don't need the cat pictures when that is close to home :)

Re: S3 is files, but not a filesystem

#439

Post by flybarrel »

wubrr wrote: post #413
pclmulqdq wrote: post #253

Earlier quoted context omitted.

When I worked at Google in storage, we had our own figures of merit that showed that we were the best and Amazon's durability was trash in comparison to us. As far as I can tell, every cloud provider's object store is too durable to actually measure ("14 9's"), and it's not a problem.

> As far as I can tell, every cloud provider's object store is too durable to actually measure ("14 9's"), and it's not a problem. How can you tell that if it's not measurable? As far as I can tell the '11/14 9s' durability numbers are more or less completely made up. That's why AWS doesn't offer any actual durability SLA for S3, only a 99.9% availability SLA[0]. [0] https://aws.amazon.com/s3/sla/

buddy you are mixing availability and durability

Re: S3 is files, but not a filesystem

#440

Post by bigiain »

dmvdoug wrote: post #362
tomcam wrote: post #355

Earlier quoted context omitted.

> if someone's dropped a warhead that close to home I have other things to worry about than whether all the cat pictures and audit logs survive. Speak for yourself. Many of us love our audit logs and show them to strangers whatever we can.

I’m picturing you having a slideshow of audit logs that you make guests to your home sit down and watch with you, like the vacation pictures slideshow of old.

Awwwww! Check out this cute little IAM audit log! Look at its funny little fizzy privilege escalation! I just want to scratch it's belly until it p0wns the whole prod deployment.
Post reply on HN