21–30 of 203 posts
Earlier quoted context omitted.
What’s the I/O throughput of /dev/null ?
Single client, I'm getting ~5GB/s, both on an 8-year-old intel server, and on my M1 ARM chip. However with a single server, it doesn't perfectly linearly scale with multiple clients. I'm getting 1 client: 5GB/s 2 clients: 8GB/s 3 client: 8.7GB/s
I've used /dev/null for exactly this purpose. I have output that needs to go somewhere, and I don't want to worry about whether that somewhere can handle it. Later on in deployment, it will go somewhere else. Somewhere that has been evaluated for being able to handle it. In that way, /dev/null is to storage what `true` is to execution - it just works.
Bug free software is a pipe dream, but if there is anything I've never encountered any bugs with, /dev/null and true is certainly in the top 3.
Both (along with a lot of the standard utilities) are a testament to what talented C programmers plus years of people beating on them in unintended ways can achieve in terms of reliability/stability.
Always instantly consistent, always available, and perfectly tolerant of partitioning. Truly, it is the only database which can be scaled to unlimited nodes and remain fully CAP.
I guess we have a perfect idea for vaporware here. (pun intended) I am putting my marketing hat on right now.
How does a disaster recovery plan with it look like?
Earlier quoted context omitted.
Single client, I'm getting ~5GB/s, both on an 8-year-old intel server, and on my M1 ARM chip. However with a single server, it doesn't perfectly linearly scale with multiple clients. I'm getting 1 client: 5GB/s 2 clients: 8GB/s 3 client: 8.7GB/s
I'm easily reaching 30GB/s with a single client: dd if=/dev/zero of=/dev/null bs=1M status=progress A second dd process hits the same speed.
yes | pv > /dev/null
Earlier quoted context omitted.
Single client, I'm getting ~5GB/s, both on an 8-year-old intel server, and on my M1 ARM chip. However with a single server, it doesn't perfectly linearly scale with multiple clients. I'm getting 1 client: 5GB/s 2 clients: 8GB/s 3 client: 8.7GB/s
I'm easily reaching 30GB/s with a single client: dd if=/dev/zero of=/dev/null bs=1M status=progress A second dd process hits the same speed.
Earlier quoted context omitted.
Bug free software is a pipe dream, but if there is anything I've never encountered any bugs with, /dev/null and true is certainly in the top 3.
Joking aside I can’t ever remember seeing a bug in either bash or zsh, never seen either crash or segfault and anytime I’ve had weirdness it’s always turned out to be me missing something. Both (along with a lot of the standard utilities) are a testament to what talented C programmers plus years of people beating on them in unintended ways can achieve in terms of reliability/stability.
Earlier quoted context omitted.
Bug free software is a pipe dream, but if there is anything I've never encountered any bugs with, /dev/null and true is certainly in the top 3.
Joking aside I can’t ever remember seeing a bug in either bash or zsh, never seen either crash or segfault and anytime I’ve had weirdness it’s always turned out to be me missing something. Both (along with a lot of the standard utilities) are a testament to what talented C programmers plus years of people beating on them in unintended ways can achieve in terms of reliability/stability.
Shellshock [0] is a rather famous example, but bugs like that are rare enough that they make the news when they're found.
[0] https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29