nmelkozerov

It is not as simple as it seems. If you connect the "unused" cell in a series, it could alter the battery's output voltage by as much as 4.2 volts, which has the potential to damage the voltage regulator.

On the other hand, if you connect the "unused" cell in parallel, it's absolutely crucial that it holds the same charge as the other cells at the time of connection. This is because the parallel pack's voltage will level out, leading to a substantial flow of current (essentially causing rapid charging/discharging of the cell). This can result in a fire or even a battery explosion if the cell voltages are too different.

All in all, physically detaching a battery might not be the best approach. The cells will experience different levels of wear, and variations in internal resistance will lead to problems with cell balancing and longer charging times.

So a quick explanation how it works:

Initially everyone is muted.

When you want to speak, you press a button. When you're done, you release the button.

If no one is currently speaking, you will be unmuted immediately. Otherwise, you will be queued and unmuted as soon as other participants finish speaking.

Sound like a good idea!

We don't use FDB in production yet, but Wavefront is using FDB and it seems they're quite happy: https://news.ycombinator.com/item?id=16879632

My next step is to implement a locking mechanism to prohibit simultaneous mounts and data corruption, and then I'll work on providing a Container Storage Interface to support easy integration with k8s.

I don't think there will be major deviations from the roadmap defined in the readme :)

It's definitely a cool idea. I think it makes sense to make it configurable, since some workloads might write already compresses bytes and then it's not possible to compress them any further.

Thanks you.

Since it is a block device, all files are splitted into chunks of 4 kb (or other value if configured) and from the database perspective there is no difference between large and small files.

For deletions, FoundationDB is able to delete a key range in O(log(n)) time, without using tombstones, and it doesn't use compactions (because it uses B-tree instead of LSM-tree) so I don't think there will be any impact on performance.

Right now TRIM operations are not supported yet, so instead of getting deleted blocks will be marked as "free" by a filesystem and then reused later.