00:41:07 is there any ARM code yet? 00:58:00 it looks like it would require linux blob driver support 13:11:55 i suspect that would depend on the specific device... 13:12:10 IIRC people have been working on it, but I'm not sure what specific devices they've been using for the effort 13:14:26 Mostly in qemu so far, but some people are running it on Raspberry Pis under PiMox too. 17:50:36 TIL pimox 17:50:52 lol 18:01:10 TIL indeed 18:01:24 didnt even know you could run virtualization on them 18:01:41 not that i have any spare > rPI2's 18:30:39 [illumos-gate] 15539 opteron_pcbe broken on pre-Zen after 10896 -- Robert Mustacchi 19:39:40 there is a lot of work left to do on ARM, but it's at a place where people could certainly help do that work 19:39:58 and I'm in the process of cleaning up some of the larger build-related crimes so I can make it a more official project with a clean conscience. 19:40:53 is anyone familiar with the B_FAILFAST semantics of a buf(9S)? 19:47:19 [illumos-gate] 15556 idmap not retrying DC discovery on failure -- Matt Barden 19:50:12 jbk: I think in the past we'd determined it did not actually fail particularly fast 19:50:29 but that's all I remember, and it might be a different failfast I'm thinking of 19:50:45 well that's what i'm wondering 19:50:59 i'm seeing _lots_ if zfs I/Os that are retrying at the sd layer 19:51:07 based on the ereport 19:53:06 and it's making me concerned that a drive that goes out to lunch long enough to time out enough I/Os but then comes back might (under heavy I/O) trigger enough sd.c caused retries to make things go non-linear 20:01:46 I'm about 99% certain it will, and has. 20:01:56 everycity had this problem for ages 20:02:13 there's this massive stack of timeouts and retries and allegedly "fast" failure semantics down the I/O stack 20:02:26 and in at least some cases, these add up to ~15 minutes 20:03:10 but doing anything about it gets you into 40 years of history, and doing anything haphazardly is as likely to make it worse or at least even more baroque 20:03:58 everyone I remember having been involved in thinking about this is busy and/or away right now. 20:13:30 jbk: I vaguely recall that B_FAILFAST was introduced for the benefit of SVM as a hint to the driver that it need not try very hard. But I believe problem is that the rest of the storage stack (especially including disk drive firmware) isn't set up to make that useful. 20:15:51 You'd need some way to tell the scsi/sata/nvme controller to abort the pending I/O if you didn't get a response within a particular deadline, and be sure that the controller wouldn't then scribble into the buffer for the cancelled I/O. 20:16:58 Or else some way to quarantine the stranded buffers until the controller said it was done with them. 20:20:13 my (likely naive) assumption would be for sd to (at least) not automatically retry a B_FAILFAST I/O 20:20:15 (oh, there's things at the disk level like the ERC/TLER but looks like the default deadline for TLER is 7 seconds) 20:20:44 which doesn't appear to be the case (from the looks of the ereports)... 20:22:17 which is why i was wondering about what exactly it's supposed to do 20:22:31 at that point, sd.c's already generated an ereport on the timeed out CDB 20:22:43 seems like it's worth an experiment at least. 20:23:05 but then it appears to be resubmitting it when presumably it should be able to just return EIO or even ETIME 20:26:29 (but there may well be cases where you need to retry because of something happening in the plumbing between the host and drive vs. something happening in the drive itself) 20:42:07 in contrast, blkdev does no retries AFAICT and just returns an error 20:51:42 ... zfs and sd.c are the only things in illumos-gate that use the flag (and it was never 'officially' documented or part of the DDI AFAICT)... 20:59:03 it would be in buf(9S) or WDD if it was. 21:00:00 jbk: you might want to look at 6740013, 6843014, 6990691, 6990700 21:00:02 (just wondering how much leeway there is to work with) 21:00:13 fenix: 6990700? 21:00:14 OpenSolaris issue 6990700: re-examine ZFS write retry policy (Dispatched) 21:00:14 ↳ https://illumos.org/opensolaris/bugdb/bug.html#!6990700 21:00:20 Did you see http://dtrace.org/blogs/jerry/2005/06/14/svm-and-the-b_failfast-flag/ ? 21:00:26 (to get you a link, so you can copy/paste the others) 21:01:14 heh.. jerry's out today :) 21:01:40 (just laughing at this coming up, he being the one working on it, and being out) 21:05:16 6843014 has a particularly interesting description, based on what you'd said. 21:10:20 ah, that's an instance of "retry needed due to plumbing issue" 21:11:10 ahh there is MPxIO involved as well.. 21:12:50 i guess I need to dig in there as well -- if it's retrying w/o B_FAILFAST set and the problem wasn't a path issue, that might explain the behavior