Show HN: A proof-of-concept FoundationDB based network block device backend

Re:Show HN: A proof-of-concept FoundationDB based network bl... by spullara on Saturday April 28, 2018 @04:14PM (#16949228)

Cool! Here is my java version that I wrote back in the day. Recently updated to 5.1.

https://github.com/spullara/nbd

[ Parent | on HN ]

Re:Show HN: A proof-of-concept FoundationDB based network bl... by dividuum on Saturday April 28, 2018 @04:35PM (#16949292)

Nice. That looks way more polished. Thanks for linking!

Upon further reading: I didn't realize that there is a TRIM command. I search briefly and missed that. Neat.

[ Parent | on HN ]

Re:Show HN: A proof-of-concept FoundationDB based network bl... by scoot on Sunday April 29, 2018 @10:37AM (#16952183)

How do you handle resilience? if FDB is multi-node, do you run a copy on each node? If so, how is failure detected / client traffic redirected, and what protects against concurrent access from multiple clients to the same volume?

[ Parent | on HN ]

Re:Show HN: A proof-of-concept FoundationDB based network bl... by spullara on Monday April 30, 2018 @10:48AM (#16958957)

See https://www.foundationdb.org for information on FDB but in short it is a distributed database that is auto-scaling, auto-healing, auto-sharding and ACID. You do need a minimum of 3 nodes to get those properties. When you connect to a volume it is protected by a lock that ensures only a single client.

[ Parent | on HN ]

Re:Show HN: A proof-of-concept FoundationDB based network bl... by scoot on Tuesday May 01, 2018 @03:48PM (#16970773)

Thanks for the reply. Don't know if you will see this, but I was also interested in how the NBD client fails over to an alternate node if the one it's connected to fails.

Regarding locking, is there a distributed lock manager? What prevents two NBD clients connecting to the same volume via two different nodes?

[ Parent | on HN ]