Hacker News Reader

Comment by derefr | Hacker News Reader

Think of it like an EC2 instance with ephemeral storage. You need an external storage service provided by the host (like EBS and S3 are for EC2), that the instances either talk to over the network (like S3), or which the host mounts into the container (like EBS.) Both are possible options with the current Docker runtime.

View on HN

Yes. And we all know how well EBS works for consistent database performance. That's why I said "... would rule out running databases in containers ..."

That is entirely irrelevant - it's an implementation detail of AWS.

The volume could just as well be bind-mounted from the same local host.

That's what I was asking in my first question: Do you get access to a raw device node of the host OS?

No, I don't think so. This is prevented by kernel namespaces and default privileges of LXC in Docker. That doesn't mean you can't bind mount a directory from your host into your container though; there's also the concept of volumes.

I don't think so, but bind-mounts makes that irrelevant for most uses. If you need bare-metal device access, then you have very specialised needs that apply to a very tiny fringe set of users (as an example, we can reach 1GB/s reads from our SSD RAID arrays on some of our containerised database servers without resorting to raw device access).

Is it GB/s or Gb/s ? Even SATA3 maxes out at 6Gb/s

I don't know if they meant GB or Gb, but for the record, I didn't see any difference in disk performance between native and containerized apps. In that case, that was pulling ~900 MB/s seq reads from a RAID10 disk array of 8 old 7k HDD. This is not surprising, as the code path for block I/O is exactly the same for native and containerized processes.

Reply on news.ycombinator.com