News for hackers. Stuff that matters.
Re:Inside the Magic Pocket by james_cowling on Friday May 06, 2016 @07:12PM (#11647379)
Yep looks like we may have had slightly different goals here. Another one of our design requirements was that we wanted to be able to move data around within the system (repair operations, rebalancing, encoding, compaction etc) without dealing with the metadata overhead of addressing hundreds of billions of blocks. Statically mapping a block to a 1GB bucket allows us to manage placement decisions on the granularity of buckets rather than orders of magnitude more individual files/blocks.
Re:Inside the Magic Pocket by jorangreef on Sunday May 08, 2016 @08:48AM (#11653814)
Thanks for sharing a great post.

Do you think a 512MB bucket might be more optimal compared to a 1GB bucket? 2x less data required to be read when restoring an erasure coded bucket, and 2x quicker restore times, for only a 2x increase in bucket metadata costs? Erasure coded bucket slices (around 85MB per slice assuming 6/9 Reed Solomon) should be just right to amortize disk seeks.

Re:Inside the Magic Pocket by james_cowling on Sunday May 08, 2016 @11:02PM (#11657344)
Thanks!

It's always a bit of a tradeoff. A 512MB bucket size would double the size of the Replication Table and we want make sure we keep the entire working set in the buffer cache. 1GB also has the advantage of filling up slower, which gives us more time to close full buckets and create new ones as needed.

That said, 1GB is a bit of an arbitrary number which just happens to work pretty well. 512MB might work just fine. The exact number isn't as significant since typically we lose a whole disk at a time and thus needs to recover a certain number of TB regardless of the bucket size.

Re:Inside the Magic Pocket by jorangreef on Monday May 09, 2016 @02:58AM (#11658040)
Thanks, that makes sense!