Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

lsr: ls with io_uring

rockorager.dev

Post reply on HN
Print view View original

141–150 of 177 posts

Re: lsr: ls with io_uring

#141

Post by Imustaskforhelp »

hnlmorg wrote: post #127
Imustaskforhelp wrote: post #10

Really interesting, the difference is real though I would just hope that some better coloring support could be added because I have "eza --icons=always -1" command set as my ls and it looks really good, whereas when I use lsr -1, yes the fundamental thing is same, the difference is in the coloring. Yes lsr also colors the output but it doesn't know as many things as eza does For example .opus will show up as a music…

“bat” is a pretty good modern “cat” https://github.com/sharkdp/bat

So I just ran strace -c cat and strace -c bat

Bat did 445 syscall Cat did 48 syscall

Sure bat does beautify some things a lot but still I just wanted to tell this, I want something that can use io_uring for cat too I think,

like what's the least number of syscalls that you can use for something like cat?

Re: lsr: ls with io_uring

#142

Post by cwillu »

ninkendo wrote: post #102
mprovost wrote: post #75

Earlier quoted context omitted.

The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff. It didn't require every existing tool, such as ls, to deal with things like the server rebooting while listing a directory. (The original NFS protocol is stateless, so clients can survive server reboots.) What does vi do when the server hosting the file you…

> The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff I don't agree that it was a reasonable tradeoff. Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. I don't think this is unique to NFS, it applies to any network filesystem you try to present as if it's a local o…

Do you have similar thoughts about iscsi?

Re: lsr: ls with io_uring

#143

Post by ninkendo »

JonChesterfield wrote: post #123
ninkendo wrote: post #102

Earlier quoted context omitted.

> The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff I don't agree that it was a reasonable tradeoff. Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. I don't think this is unique to NFS, it applies to any network filesystem you try to present as if it's a local o…

> Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. It's the only idea though. We don't know how to make reliable systems, other than by cobbling together a lot of unreliable ones and hoping the emergent behaviour is more reliable than that of the parts.

I think a difference in magnitude turns into a difference in kind. There's lots of systems where the unreliability of the underlying parts is low enough that it can be a simple matter of retrying quickly once or twice (bit flips in ECC RAM), and others where at least the unreliability is well-known enough that software has all learned to work around the leaky abstraction (like TCP. Although QUIC and other protocols show that maybe it's better to move the unreliability up a layer for more intelligent handling of the edge cases.)

But the unreliability of "the network" compared to "my SATA port" is a whole different ballgame. Filesystems are designed for the latter, and when software uses filesystems it generally expects a reliability guarantee that "the network" can't really provide. Especially on mobile internet, wifi, etc... And that's not even getting into places where NFS just can't do things that local filesystems can do (has anyone figured out how to make inotify/fsevents work?) and all the software that subtly breaks because of it.

Re: lsr: ls with io_uring

#144

Post by burntsushi »

porridgeraisin wrote: post #132
burntsushi wrote: post #110

Earlier quoted context omitted.

No, ripgrep doesn't use io_uring. Idk if it ever will.

Curious: Why? Is it not a good fit for what ripgrep does? Isn't the sort of "streaming" "line at a time" I/O that ripgrep does a good fit for async io?

For many workloads, ripgrep spends the vast majority of its time searching through files.

But more practically, it would be a terror to implement. ripgrep is built on top of platform specific standard file system APIs. io_uring would mean a whole heap of code to work with a different syscall pattern in addition to the existing code pattern for non-Linux targets.

So to even figure out whether it would be worth doing that, you would need to do a whole bunch of work just to test it. And because of my first point above, there is a hard limit on how much of an impact it could even theoretically have.

Where I would expect this to help is to batch syscalls during directory tree traversal. But I have nonidea how much it would help, if at all.

Re: lsr: ls with io_uring

#145

Post by Asmod4n »

yencabulator wrote: post #98
Bender wrote: post #12

I am curious what would happen if ls and other commands were replaced using io_uring and kernel.io_uring_disabled was set to 1. Would it fall back to an older behavior or would the ability to disable it be removed?

I just realized that one could probably write a userspace io_uring emulator in a library that spawns a thread to read the ringbuffer and a worker pool of threads to do the blocking operations. You'd need to get the main software to make calls to your library instead of the io_uring syscalls, that's it; the app logic could remain the same. Then all the software wanting to use io_uring wouldn't need to write their low-…

I'm about to start something like this targetting epoll, poll, dispatch_io and maybe kqueue this weekend.

Re: lsr: ls with io_uring

#146

Post by scott_w »

leni536 wrote: post #138
scott_w wrote: post #48

Earlier quoted context omitted.

Depending on the implementation (and I don't know which `ls` is being referred to), modifying `ls` might mean modifying an FSF project which require copyright assignment as a condition of patch submissions.

That's only the case if the author would want to upstream their changes. If they wanted to only fork ls then they would only be required to comply with the license, without assigning copyright over.

That may be the case but then why bother modifying ls when you can just write your own exactly as you want it?

Re: lsr: ls with io_uring

#147

Post by yencabulator »

api wrote: post #114
yencabulator wrote: post #76

Earlier quoted context omitted.

Not speaking of ls which is more about metadata operations, but general file read/write workloads: io_uring requires API changes because you don't call it like the old read(please_fill_this_buffer). You maintain a pool of buffer that belong to the ringbuffer, and reads take buffers from the pool. You consume the data from the buffer and return it to the pool. With the older style, you're required to maintain O(pendin…

In a single threaded flow your buffer pool is just the buffer you were given, and you don't return until the call completes. There are no actual concurrent calls in the ring. All you're doing is using io_uring to avoid syscall. Other replies lead me to believe it's not worth doing though, that it would not actually save syscalls and might make things worse.

Can you use io_uring in a way that doesn't gain the benefits of using it? Yes. Does the traditional C/POSIX API force you into that pattern? Almost certainly.

Re: lsr: ls with io_uring

#148

Post by the8472 »

loeg wrote: post #68
the8472 wrote: post #41

io_uring doesn't support getdents though. so the primary benefit is bulk statting (ls -l). It'd be nice if we could have a getdents in flight while processing the results of the previous one.

POSIX adopting NFS' "readdirplus" operation (getdents + stat) could negate some of the benefit towards io_uring, too.

but then someone wants statx...

Re: lsr: ls with io_uring

#149

Post by cb321 »

rockorager wrote: post #83

Author of the project here! I have a little write up on this here: https://rockorager.dev/log/lsr-ls-but-with-io-uring

At those time scales, you would be better off using `tim` ( https://github.com/c-blake/bu/blob/main/doc/tim.md ) than hyperfine { and not just because that is your name! Lol. That is just a happy coincidence by clipping one letter off of the word "time". :-) } even though being in Nim might make it more of a challenge.

Re: lsr: ls with io_uring

#150

Post by Someone »

mprovost wrote: post #75
ninkendo wrote: post #9

I wonder how it performs against an NFS server with lots of files, especially one over a kinda-crappy connection. Putting an unreliable network service behind blocking POSIX syscalls is one of the main reasons NFS is a terrible design choice (as can be seen by anyone who's tried to ctrl+c any app that's reading from a broken NFS folder), but I wonder if io_uring mitigates the bad parts somewhat.

The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff. It didn't require every existing tool, such as ls, to deal with things like the server rebooting while listing a directory. (The original NFS protocol is stateless, so clients can survive server reboots.) What does vi do when the server hosting the file you…

> The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive),

> The original NFS protocol is stateless,

The protocol is, but the underlying disk isn’t.

- A stateless emulation doesn’t know of the concept of “open file”, so “open for exclusive access” isn’t possible, and ways to emulate that were bolted on.

- In a stateless system, you cannot open a scratch file for writing, delete it, and continue using it, in the expectation that it will be deleted when you’re done using it (Th Unix Hater’s handbook (https://web.mit.edu/~simsong/www/ugh.pdf) says there are hacks inside NFS to make this work, but that makes the protocol stateful)

> It didn't require every existing tool, such as ls, to deal with things like the server rebooting while listing a directory

But see above for an example where every tool that wants to do record locking or get exclusive access to a file has to know whether it’s writing to a NFS disk to figure out how to do that.

Post reply on HN