a bit random, but does anyone know offhand if the kernel ever updates /etc/path_to_inst, or is that always done from userland?

(or vice versa)

(if userland, i wanted to experiment with addign it as a boot module from the local disk and then lofi mount in the running os)

so it can be persistent even with a ramdisk based setup

[illumos-gate] 15613 SMB2 Large MTU support -- Gordon Ross <gordon.ross⊙tc>

*sigh* one thing that would be nice is if standards included a history for a feature (e.g. 'first appears in version X') so you don't have to chase down older versions to answer that

indeed. The python docs at python.org seem to get this right (plus you can pull up the older versions in a couple clicks)

(among many other things), I'm hoping to work on some improvements with how ZFS talks to disks

e.g. there's an existing 'don't cache' flag for buf(9S) that zfs sets, but doesn't actually get used by anything

(B_DONTNEED IIRC)

err B_NOCACHE

could also set a flag in the READ/WRITE CDBs (at least for SCSI disks) to tell the disk to not cache

as well as when zfs says don't retry, have sd.c not retry the failed I/O

(our timeout/retry defaults here are horrible and were probably marginally ok for disks 25-30 years ago)

Unfortunately standards are often that way and just is the nature of the beast.

yeah.. the scsi ones are far from the only ones that do it

I'll be curious to see what you come up with here.

looks like B_NOCACHE does get used in bio.c (leads to the buf getting freed sooner). I'd worry about dumb firmware misinterpreting it.

("it" being the SCSI equivalent of B_NOCACHE)

i'd probably add in a hook to disable it via sd.conf like some of the other behaviors..

the bigger one though is if the disk has an uncorrectable media error, it returns EIO to zfs, which AFAICT never attempts self-healing in that instance

but sd.c could tell the drive to attempt to remap that block

at which point self healing could be used to repair it

(or on a write, just retry the write after remapping the block)

(also, might be nice to enable background scanning via fmd or such.. it's supposed to at least be non-impacting)

hard part would be if as a result of the scan the disk says, unsolicited, "block 8675309 is unreadable". would be hard to find the block pointer that has the checksum that covers that block..

scrub at least has that context.

yeah.. for bad blocks discovered asynchronously, it might just be use that to trigger a scrub

presumably you could tell if it's allocated or free. (free -> just remap it to zeros; alloc -> add to suspect list and schedule a scrub?)

maybe.. i need to look at more to see how easily that can be discerned

mapping back from lba -> slice -> metaslab might be messy but should presumably be doable but might involve a bunch of io to read the metaslab metadata.

at minimum, fma could at least know from a scrub 'yeah, i'm expecting errors on these blocks' based on the bad block list after a media scan

(at some point, I'd also like to make the disk & zfs modules a little smarter... right now a bad disk can cause them to step on top of each other)

i don't know if it's possible, but like if the disk module thinks the disk is bad, but is a whole disk zfs disk, have a way to tell and defer to the zfs module

right now when it retires a disk, it can kinda pull the rug out from zfs

and the zfs module might be trying to do things too

yep, I've noticed it's quick to mark a disk "removed" requiring what looks like a full rebuild after it returns (and likely messing with the increased robustness that the DTL should give you)

yeah, at least some disk manuf have told us it's normal/ok to have a certain # of defects

if it's offline for minutes or hours, a DTL-pruned resilver should complete quickly but i don't see that happening. I'd still run a scrub afterwards just to be sure but...