Date: Wed, 13 Mar 2024 17:02:36 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277673] TRIM visibility bugs Message-ID: <bug-277673-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277673 Bug ID: 277673 Summary: TRIM visibility bugs Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: mgrooms@shrew.net Hey All, While toying with different storage options to use with bhyve, I've run acr= oss a few frustrations related to visibility into TRIM operations. Specifically, it's not always easy to tell if trim operations are being processed by a hardware device due to the counters not being updated by the SCSI da device. The counters exported as sysctl values are updated by the SCCI UNMAP method, but not by the TRIM or WD methods. You can see the BIO_DELETE opterations b= eing processed in real time by running the gstatus -d command, but the counters never change from 0. This gives the false illusion that nothing is happenin= g. With the following patch, I'm now able to see the counters reflect trim operations that are processed by da devices ... mgrooms@mgrooms:~/trim $ cat scsi_da.diff --- scsi_da.c.orig 2024-03-13 11:32:32.098922000 -0500 +++ scsi_da.c 2024-03-13 11:31:37.255187000 -0500 @@ -4197,6 +4197,9 @@ da_default_timeout * 1000); ccb->ccb_h.ccb_state =3D DA_CCB_DELETE; ccb->ccb_h.flags |=3D CAM_UNLOCKED; + softc->trim_count++; + softc->trim_ranges +=3D ranges; + softc->trim_lbas +=3D block_count; cam_iosched_submit_trim(softc->cam_iosched); } @@ -4257,6 +4260,8 @@ da_default_timeout * 1000); ccb->ccb_h.ccb_state =3D DA_CCB_DELETE; ccb->ccb_h.flags |=3D CAM_UNLOCKED; + softc->trim_count++; + softc->trim_lbas +=3D count; cam_iosched_submit_trim(softc->cam_iosched); } Additionally, while attempting to test geom mirror+stripe to provide softwa= re RAID10, the diskinfo utility reports that a mirror supports UNMAP/TRIM when= at least one underlying devices supports it, but a stripe does not. I added a small patch that attempts to use the same logic as mirror so that it will report that UNMAP/TRIM is supported when one of the underlying devices does= ... --- g_stripe.c.orig 2024-03-12 18:23:52.960025000 -0500 +++ g_stripe.c 2024-03-12 18:25:01.009378000 -0500 @@ -26,6 +26,7 @@ * SUCH DAMAGE. */ +#include <sys/cdefs.h> #include <sys/param.h> #include <sys/systm.h> #include <sys/kernel.h> @@ -568,7 +569,7 @@ off_t offset, start, length, nstripe, stripesize; struct g_stripe_softc *sc; u_int no; - int error, fast =3D 0; + int error, fast =3D 0, val =3D 0; sc =3D bp->bio_to->geom->softc; /* @@ -591,6 +592,12 @@ g_stripe_pushdown(sc, bp); return; case BIO_GETATTR: + if (!strcmp(bp->bio_attribute, "GEOM::candelete")) { + if (sc->sc_flags & G_STRIPE_FLAG_CANDELETE) + val =3D 1; + g_handleattr(bp, "GEOM::candelete", &val, sizeof(val)); + return; + } /* To which provider it should be delivered? */ default: g_io_deliver(bp, EOPNOTSUPP); @@ -745,7 +752,7 @@ { struct g_consumer *cp, *fcp; struct g_geom *gp; - int error; + int error, i; g_topology_assert(); /* Metadata corrupted? */ @@ -792,8 +799,19 @@ goto fail; } } - sc->sc_disks[no] =3D cp; + + /* cascade candelete */ + error =3D g_access(cp, 1, 0, 0); + if (error =3D=3D 0) + { + error =3D g_getattr("GEOM::candelete", cp, &i); + if (error =3D=3D 0 && i !=3D 0) + sc->sc_flags |=3D G_STRIPE_FLAG_CANDELETE; + G_STRIPE_DEBUG(1, "Provider %s candelete %i.", pp->name, i); + g_access(cp, -1, 0, 0); + } + G_STRIPE_DEBUG(0, "Disk %s attached to %s.", pp->name, sc->sc_name); g_stripe_check_and_run(sc); --- g_stripe.h.orig 2024-03-12 18:24:00.960741000 -0500 +++ g_stripe.h 2024-03-12 12:25:22.842925000 -0500 @@ -47,6 +47,8 @@ #define G_STRIPE_TYPE_MANUAL 0 #define G_STRIPE_TYPE_AUTOMATIC 1 +#define G_STRIPE_FLAG_CANDELETE 0x00000001UL + #define G_STRIPE_DEBUG(lvl, ...) \ _GEOM_DEBUG("GEOM_STRIPE", g_stripe_debug, (lvl), NULL, __VA_ARGS__) #define G_STRIPE_LOGREQ(bp, ...) \ @@ -61,6 +63,7 @@ uint16_t sc_ndisks; off_t sc_stripesize; uint32_t sc_stripebits; + uint32_t sc_flags; struct mtx sc_lock; }; #define sc_name sc_geom->name --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277673-227>