[00:27] <keithzg[m]> sarnold: Pretty sure these are not SMR drives, these are older Western Digital Reds (4TB) from long before that brief period a year or two ago where they were selling SMR drives without telling anyone. Specifically, all four are WDC WD40EFRX-68WT0N0.
[00:28] <keithzg[m]> Of course, doesn't necessarily mean that they don't suck enough at sustained writes that such performance is nonetheless the fundamental problem here!
[00:32] <shibboleth> https://www.techspot.com/news/84973-wd-publishes-complete-list-smr-drives-following-user.html
[00:33] <shibboleth> https://nascompares.com/answer/list-of-wd-cmr-and-smr-hard-drives-hdd/
[00:34] <shibboleth> cmr
[00:40] <sarnold> keithzg[m], shibboleth, good news for keithzg[m], but it's a bit of a bummer to be wrong so many times. heh.
[00:40] <shibboleth> indeed
[00:40] <shibboleth> don't buy wd drives
[00:40] <shibboleth> get a toshiba n300
[00:41] <shibboleth> cheaper, 7200rpm, better
[00:41] <keithzg[m]> Err, Toshiba has also without documentation used SMR . . . the real problem here is the market of HDD manufacturers is very small and they're all a bit sketchy :P
[00:43] <keithzg[m]> For ages this array wasn't a problem though, often limited more by networking and i/o on the other end than on the storage server end, so it's particularly baffling to me that it's suddenly seemingly a problem as of this month :(
=== XMOPX is now known as xmopx
=== tinwood is now known as tinwood-afk
=== tinwood-afk is now known as tinwood
[14:43] <smoser> rbasak: it looks like https://code.launchpad.net/ubuntu/+source/sshuttle is not being updated.
[14:43] <smoser> i understood that that should happen magically, is that not true ?
[14:43]  * rbasak looks
[14:44] <smoser> groovy-devel and focal-devel are out of date (focal should have a -proposed entry 0.78.5-1ubuntu1  i thought)
[14:47] <rbasak> I agree. I wonder if the whitelist is being ignored.
[14:50] <rbasak> Yes there is something wrong here.
[14:53] <rbasak> Let me kick sshuttle manually for you, and I'll look into why that happened
[14:54] <rbasak> OK that's running
[15:09] <rbasak> smoser: updated. Sorry about that. I'll chase down the actual bug.
[15:09] <rbasak> It seems like quite a few packages are affected, but not all.
[15:49] <smoser> rbasak: thanks
[17:19] <sergiodj> mdeslaur: hey, I found the problem with mysql on risc-v and have a patch for it (not very pretty, but it works).  I'm recompiling to see if everything works, but it'll take a few hours
[17:19] <sergiodj> just a heads up :)
[17:19] <mdeslaur> sergiodj: oh, sweet :)
[17:30] <gregor3000> hello,
[17:31] <gregor3000> can anyone point me to a good SSH guide. i created a new user on server and i can't get it to connect. i moved the pub to server, i added the authorised key filed and copied in the string, but it gives me wrogn key verification
[17:31] <gregor3000> host key verification failed.
[17:32] <gregor3000> i can connetc to server using current user and key, but not using new user. the new user is just on server.
[17:32] <gregor3000> most guides tlak abotu setting firts user with password, then keys,then disabling password.
[17:48] <RoyK> gregor3000: check the logs
[17:49] <RoyK> gregor3000: /var/log/auth.log is a good start
[17:56] <gregor3000> do i need to call specific port when connecting?
[18:00] <keithzg[m]> gregor3000: Only if you did something special with the config in the first place, ssh should be serving on port 22 by default and client programs will assume the same.
[18:01] <gregor3000> ok so i messed up something with keys (maybe permissions or something). i think i will need to call my bro to help me out.
[20:20] <keithzg[m]> sarnold: Tried checking `dmesg` when the i/o lockups were happening today, alas the only lines were ones generated by me running `perf top`. The mystery continues . . .
[20:31] <rangergord> keithzg[m], could you use atop to record active resource consumption, and replay the history file afterwards?
[20:34] <keithzg[m]> rangergord: Can't say I'm too familiar with `atop` but I'm certainly willing to give it a try! Will a straight-up invocation of it, left running in a screen session, be sufficient? Or are there some options I should be using?
[20:36] <rangergord> I can't remember if it records to a file by default or not
[20:36] <rangergord> probably not. But I do remember replaying a recorded file using 'atop -someflag oldfile' and browsing the past interactively
[20:44] <keithzg[m]> rangergord: Looks like it's automatically logging to `/var/log/atop`
[20:46] <rangergord> cool, sorted then :)  it logs any process that used resources (CPU, disk...network but you need to set that up), so once the issue happens, you use the keyboard shortcuts to navigate in time to see what went wrong hopefully
[20:46] <rangergord> I haven't used it more than once, but I plan on using it on my systems when I have some free time to read the doc
[20:48] <keithzg[m]> Yeah I've always just made do with `top` and maybe `iotop`, with checking normal system logs to introspect in time instead of just the present moment. But my current problem sure seems to call for further measures! Thanks for the suggestion, rangergord :)
[20:48] <rangergord> yw