I'll note, lsblk can return a heck of a lot more data than it does by default (and nvme drives show up there). lsblk -H will list for your system, and you can specify columns. You can also adjust output.
I guess with this in mind, I'm curious how this is different?
Hi, yep lsblk targets a wider area of functionality, like showing mountpoints, device UUIDs, while lsds focuses only on block device settings.
Maybe the latest Linux versions have lsblk versions that support these columns, but in RHEL9 at least I don't see equivalents to lsds'es WBT_LAT, QDEPTH (not the same as lsblk's RQ-SIZE), WCACHE, FUA and some others. But these 4 are which I regularly need (especially when troubleshooting a yet another slow fsync() issue etc). I did and do use lsblk all the time too, but still end up catting and grepping various additional files and correlating the results, sometimes on systems with 100+ multipath block devices.
The other reason was that I wanted a tool that shows me where it gets these values too (for myself and sometimes for explaining stuff to others).
Edit: That being said, it shouldn't be hard at all to add the said extra fields to lsblk too.
Would be worth adding this as an FAQ on the page. Great job btw.
EDIT: Would also be really cool to define what each field means, if you're gonna reimplement everything anyways, why not make it as user friendly as possible.
Thanks. Yep I have to revamp the whole 0x.tools webpage, right now it's a mix of older tools & prototypes and the "final stuff" and it's confusing what's what.
The lsds verbose option shows where in the Linux /sys fs each individual field comes from (lsds -lpv) so that's the ultimate source of what each field means. But I could pull each sysfs file's description from docs into a table on the webpage (I'm probably too lazy to create a manpage for now - help is appreciated)
Edit: Since there are not that many fields, it would be possible to add a -d option in addition to -v to get a human readable description for each field too. One of the main sources of confusion is the "queue_depth" vs. "nr_requests" fields. My ideal (which I usually don't reach) is to make these tools "explainable", so that they tell you from where they got their input data (and what basic math was applied).
I always wanted the /dev/zero character device driver, which you can map into memory to clear it, or use as an infinite source of nulls, to use the minor node number as the value that got mapped into memory or produced, so you could make an infinite source of beeps with:
mknod /dev/seven c 1 7
I wonder what would happen if you made a /dev/seven device in your http servers public_html directory? Would it dutifully serve it up?
Better yet, support for utf-8 unicode, so you can make an infinite source of poo emojis.
The "Everything Is A File" philosophy should be taken to its logical conclusion.
Question: what actually reads /etc/pooper to configure the character? I can’t work out how that file’s contents ends up as module parameters and I’d love to know!
>We now skip back in time a little, where we find Ronald Reagan before his mysterious transformation. He presides over an America that has no concept of toilets, and piles of feces on every street corner are becoming a serious problem. Fortunately, science can help; a farmer has stumbled across a small portal to another dimension. The solution is clear; push America's mounting shit through the portal via a huge funnel. The exit point for the portal is in fact the anus of the gentleman who couldn't stop shitting back in the prison in Ed's world; so there is at least a good scientific explanation for that little episode.
>During the official opening of the shit disposer, Reagan tragically falls into the giant collection of pending waste. His body blocks the funnel, but not before his head has gone through the portal; a headless president is recovered. A scientist heads though the portal on a rescue mission.
>(Now, I know what you're thinking, and I've no idea how Reagan's head became attached to the end of Ed's penis. It makes no sense, even within the logic of Ed's universe, and it's not explained. If you have any notions, please let me know - but for now, we'll just have to accept that somehow, it happened...)
I just added a little comment/errata regarding the NVME_QDEPTH column to the post (search for errata). I should probably rename that column to emphasize that (for now) it’s the Linux nvme module level max QD and not the hardware one (it’s complicated…)
I'll note, lsblk can return a heck of a lot more data than it does by default (and nvme drives show up there). lsblk -H will list for your system, and you can specify columns. You can also adjust output.
I guess with this in mind, I'm curious how this is different?
Hi, yep lsblk targets a wider area of functionality, like showing mountpoints, device UUIDs, while lsds focuses only on block device settings.
Maybe the latest Linux versions have lsblk versions that support these columns, but in RHEL9 at least I don't see equivalents to lsds'es WBT_LAT, QDEPTH (not the same as lsblk's RQ-SIZE), WCACHE, FUA and some others. But these 4 are which I regularly need (especially when troubleshooting a yet another slow fsync() issue etc). I did and do use lsblk all the time too, but still end up catting and grepping various additional files and correlating the results, sometimes on systems with 100+ multipath block devices.
The other reason was that I wanted a tool that shows me where it gets these values too (for myself and sometimes for explaining stuff to others).
Edit: That being said, it shouldn't be hard at all to add the said extra fields to lsblk too.
Would be worth adding this as an FAQ on the page. Great job btw.
EDIT: Would also be really cool to define what each field means, if you're gonna reimplement everything anyways, why not make it as user friendly as possible.
Thanks. Yep I have to revamp the whole 0x.tools webpage, right now it's a mix of older tools & prototypes and the "final stuff" and it's confusing what's what.
The lsds verbose option shows where in the Linux /sys fs each individual field comes from (lsds -lpv) so that's the ultimate source of what each field means. But I could pull each sysfs file's description from docs into a table on the webpage (I'm probably too lazy to create a manpage for now - help is appreciated)
Edit: Since there are not that many fields, it would be possible to add a -d option in addition to -v to get a human readable description for each field too. One of the main sources of confusion is the "queue_depth" vs. "nr_requests" fields. My ideal (which I usually don't reach) is to make these tools "explainable", so that they tell you from where they got their input data (and what basic math was applied).
I always wanted the /dev/zero character device driver, which you can map into memory to clear it, or use as an infinite source of nulls, to use the minor node number as the value that got mapped into memory or produced, so you could make an infinite source of beeps with:
mknod /dev/seven c 1 7
I wonder what would happen if you made a /dev/seven device in your http servers public_html directory? Would it dutifully serve it up?
Better yet, support for utf-8 unicode, so you can make an infinite source of poo emojis.
The "Everything Is A File" philosophy should be taken to its logical conclusion.
Awesome! That actually inspired me to code this: https://codeberg.org/mco-system/pooper
I challenge anyone to find another place on the Internet where one person's joke is another person's kernel module.
Astute observation, but also CrowdStrike would like a word :-)
Question: what actually reads /etc/pooper to configure the character? I can’t work out how that file’s contents ends up as module parameters and I’d love to know!
You are absolutely right, the /etc/pooper file was never loaded.
The code has been updated and now you can change the pooped char on the fly with something like :
`echo "<WHATEVER UTF-8 CHAR>" | sudo tee /sys/module/pooper/parameters/char_utf8`
/etc/pooper file and module unload/reload are no more needed :)
Thanks for clarifying, and implementing this essential feature!
Finally somebody who gives a shit! Thank you for dropping that generous contribution.
Now I can use that device as an RSS feed! That puts the log into blog.
I haven't seen that much shit emerge from a wormhole since the Ed the Happy Clown episode of Yummy Fur comics:
https://everything2.com/node/1485685?bookmark_site=twitter&o...
>We now skip back in time a little, where we find Ronald Reagan before his mysterious transformation. He presides over an America that has no concept of toilets, and piles of feces on every street corner are becoming a serious problem. Fortunately, science can help; a farmer has stumbled across a small portal to another dimension. The solution is clear; push America's mounting shit through the portal via a huge funnel. The exit point for the portal is in fact the anus of the gentleman who couldn't stop shitting back in the prison in Ed's world; so there is at least a good scientific explanation for that little episode.
>During the official opening of the shit disposer, Reagan tragically falls into the giant collection of pending waste. His body blocks the funnel, but not before his head has gone through the portal; a headless president is recovered. A scientist heads though the portal on a rescue mission.
>(Now, I know what you're thinking, and I've no idea how Reagan's head became attached to the end of Ed's penis. It makes no sense, even within the logic of Ed's universe, and it's not explained. If you have any notions, please let me know - but for now, we'll just have to accept that somehow, it happened...)
The Chester Brown Interview:
https://www.tcj.com/the-chester-brown-interview/3/
Best NSFW Ronald Reagan Quote Ever:
https://the-comics-journal.sfo3.digitaloceanspaces.com/wp-co...
Support Indie Comics!
Easy to get an infinite stream of bell codes with: yes ^V^G
Very nice, needs option for json/jsonl output.
Thanks! Yep I was thinking of doing that next, will be very easy as under the hood the data is stored in Python dictionaries.
Rewrote most of the functionality in C as an exercise
https://gist.github.com/grahameger/2507019334f07036f84080a87...
can we package this for Arch? Arch Defense Taskforce where you at?
If you came to represent... https://wiki.archlinux.org/title/Creating_packages
Maintaining an AUR package can be great fun and an instructive glimpse into what FLOSS maintainers go through.
I just added a little comment/errata regarding the NVME_QDEPTH column to the post (search for errata). I should probably rename that column to emphasize that (for now) it’s the Linux nvme module level max QD and not the hardware one (it’s complicated…)