is there any ARM code yet?

it looks like it would require linux blob driver support

i suspect that would depend on the specific device...

IIRC people have been working on it, but I'm not sure what specific devices they've been using for the effort

Mostly in qemu so far, but some people are running it on Raspberry Pis under PiMox too.

TIL pimox

lol

TIL indeed

didnt even know you could run virtualization on them

not that i have any spare > rPI2's

[illumos-gate] 15539 opteron_pcbe broken on pre-Zen after 10896 -- Robert Mustacchi <rm⊙fo>

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

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.

is anyone familiar with the B_FAILFAST semantics of a buf(9S)?

[illumos-gate] 15556 idmap not retrying DC discovery on failure -- Matt Barden <mbarden⊙rc>

jbk: I think in the past we'd determined it did not actually fail particularly fast

but that's all I remember, and it might be a different failfast I'm thinking of

well that's what i'm wondering

i'm seeing _lots_ if zfs I/Os that are retrying at the sd layer

based on the ereport

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

I'm about 99% certain it will, and has.

everycity had this problem for ages

there's this massive stack of timeouts and retries and allegedly "fast" failure semantics down the I/O stack

and in at least some cases, these add up to ~15 minutes

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

everyone I remember having been involved in thinking about this is busy and/or away right now.

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.

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.

Or else some way to quarantine the stranded buffers until the controller said it was done with them.

my (likely naive) assumption would be for sd to (at least) not automatically retry a B_FAILFAST I/O

(oh, there's things at the disk level like the ERC/TLER but looks like the default deadline for TLER is 7 seconds)

which doesn't appear to be the case (from the looks of the ereports)...

which is why i was wondering about what exactly it's supposed to do

at that point, sd.c's already generated an ereport on the timeed out CDB

seems like it's worth an experiment at least.

but then it appears to be resubmitting it when presumably it should be able to just return EIO or even ETIME

(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)

in contrast, blkdev does no retries AFAICT and just returns an error

... 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)...

it would be in buf(9S) or WDD if it was.

jbk: you might want to look at 6740013, 6843014, 6990691, 6990700

(just wondering how much leeway there is to work with)

fenix: 6990700?

OpenSolaris issue 6990700: re-examine ZFS write retry policy (Dispatched)

↳ illumos.org/opensolaris/bugdb/bug.html#!6990700

Did you see dtrace.org/blogs/jerry/2005/06/14/svm-and-the-b_failfast-flag ?

(to get you a link, so you can copy/paste the others)

heh.. jerry's out today :)

(just laughing at this coming up, he being the one working on it, and being out)

6843014 has a particularly interesting description, based on what you'd said.

ah, that's an instance of "retry needed due to plumbing issue"

ahh there is MPxIO involved as well..

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