zfcp_scsi_te...ate_rport_io(9)

📦 version 7.3.1, in nixpkgs unstable

💅 NAME 💅

zfcp_scsi_terminate_rport_io — bestie, this one terminates all I/O on a rport. That's the whole vibe. All the pending stuff on that port? Gone. Closed. Done. ✨

🦋 SYNOPSIS 🦋

void zfcp_scsi_terminate_rport_io (struct fc_rport *rport );

🎀 ARGUMENTS 🎀

  • rport — the FC rport where we're gonna terminate the I/O. (The og manpage literally spells it "teminate" 😭 iconic typo behavior, but yes: this is the port we're shutting down I/O on. 💅)

🌸 DESCRIPTION 🌸

Okay so here's the tea: this function aborts all pending SCSI commands for a port by closing the port. Like, not just waving at them, actually closing the port. Periodt. 🔥

And the way it does it? It goes through a reopen — and that's on purpose, because using a reopen avoids a conflict with a shutdown overwriting a reopen. The manpage said it, not me. 🫶

Also there's this "forced" situation going on, and it's there for a real reason: the "forced" ensures that a disappeared port is not opened again as valid due to the cached plogi data in non-NPIV mode. So yeah — no zombie port coming back thinking it's all that because of stale cached plogi data when you're in non-NPIV mode. Nope. Not on our watch. 💀

Fr fr, don't skip the forced part. A port that disappeared should stay disappeared, not ghost back in as "valid" because of the cache. 🧚

🦋 SEE ALSO 🦋

⭐ sign-off ⭐

This lil masterpiece comes to you from ./drivers/s390/scsi, dated October 2026, and it's filed under zfcp_scsi_te...ate_rport_io(9) — yes the title got truncated mid-name and honestly it's giving main character energy. 💖 Go read the other zfcp_scsi pages, they're a whole fam. 🎀

📦 where this page comes from