From nobody Sun Nov 26 21:00:02 2023 X-Original-To: scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sdh1b2TY3z522Kf for ; Sun, 26 Nov 2023 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sdh1b0dfJz3gkl for ; Sun, 26 Nov 2023 21:00:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701032403; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZVedEUg8/Lt7peDGSetxEu7x/2HgL5oJn8ZnbtbIb3w=; b=PBFTkjkX07AZZwL00kSxfb+PtgiQ/NZ+2nK3p5oCYgI8ReZvceVihgJlAhbP7VY9wTPRaF 8yl3I4hGKrOiowZXT/v5+BqtSGr5rSzqRmJlHLLF9432FiY89Re6S0nm82ikNoHjPRD3uF kfK+dCG01k9Mu7BBN2kHhWVo/g6Nhw7IZuV5fy/A9Snha26FcFgAOyd/1QSQsHJGzRJ7aT m1uggAG32DiBZJZ15z+XiBHUQ18ovyizNw6GjaOulyk+Hb5QJDTu+CFRAa3Pc3jESfgVME 6tb5oYY12Iht6EldbdkAC5ygy4LFv7qG3aQhwQT2GleW9re9v13EI9Ne24dKVA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701032403; a=rsa-sha256; cv=none; b=fMppjGgcxiNR7mYnZ/eM26bVnWMTAy4dNznkyu4oao+uNBaK5AKRUtIl+uFnFlQNt1RV3S iTLUbXUoIdsll8tsng/PoRp1LAnptbjWKVYiB1ULFgj7R2KF0YqaYqOJ7dt6r8sEOQ27JQ oi4lryxfeyS4wF9DeD9qsIWXSmNxjSJYtMyFiLJwq9wl3sFz1J+bUzz0HDKc98zI1Ac21T Q0Z+lcHJpp0qTv7gA9w6zT1AkGZKurBVU5sERrsemUk2ovpjC6z/p0xFU2eBJQ7j64jE2m 0B+zxn9D3MbL0XTrnfWXPoc/wRMlEj5CspfoBDJyO4baS69jYdqDKF5WPNvO6Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Sdh1Z6lTWz18QS for ; Sun, 26 Nov 2023 21:00:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3AQL02If011845 for ; Sun, 26 Nov 2023 21:00:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3AQL02D7011840 for scsi@FreeBSD.org; Sun, 26 Nov 2023 21:00:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202311262100.3AQL02D7011840@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: scsi@FreeBSD.org Subject: Problem reports for scsi@FreeBSD.org that need special attention Date: Sun, 26 Nov 2023 21:00:02 +0000 List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17010324025.37A69.10853" Content-Transfer-Encoding: 7bit --17010324025.37A69.10853 Date: Sun, 26 Nov 2023 21:00:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 221952 | cam iosched: Fix trim statistics 1 problems total for which you should take action. --17010324025.37A69.10853 Date: Sun, 26 Nov 2023 21:00:02 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    221952 | cam iosched: Fix trim statistics

1 problems total for which you should take action.
--17010324025.37A69.10853-- From nobody Sun Dec 10 03:44:54 2023 X-Original-To: scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SnrP33K0Tz53yYc for ; Sun, 10 Dec 2023 03:45:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SnrP23PSrz3L7Q for ; Sun, 10 Dec 2023 03:45:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b="pWH/nn2A"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::134) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-50bfe99b6edso3996022e87.1 for ; Sat, 09 Dec 2023 19:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1702179906; x=1702784706; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zvtpaOW8q3hQqDj3yNrU/0EDfQ0ke4lmnQ6T3sbrtXA=; b=pWH/nn2AHxOSMixPnPRvqMlYteLbAlKYG4HHNWRqn5AM7zyR5HGJBlc7dmDgmugtVq CdR2kCakgVvQCMjnDT3t1X/IHI8uhUntXZlAyA3CNc+0aGDE1mkHaPAgs98lSPAdZtsj aNXQDUaD4dJFnzLhN+oOpVheNmeTr1UVUmKt2mURCBBfwXPa9QVh/usTBrS86p5PkuYV tKIiPaCjwldhZZFkbSHSdNKE+1NEB5q9JxCiQloNDbqBpvV7MghSkq1UfvFL423+mahT ovGRsVCaJ5pNSo8iTpt4x6VzRIazYIg7qvrmfT/jJjG+S/+Y28PpH0R/jeE2RghOgszQ j6uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702179906; x=1702784706; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zvtpaOW8q3hQqDj3yNrU/0EDfQ0ke4lmnQ6T3sbrtXA=; b=iysgyeJA4xlI36sEAf5cbXJBcXphgLy7crcHMiQNRVPZNr57YgiwX7Uztvv59DTgG3 rDseUuExbYDTeqpk2Khcgx5B1FwykQ3ZUifRCQPvld0Yv+LXEdjf/yQgnNmiS1IbSmGf 42HASN4KRXyQMKfEM9nUAoms3OAaJkM/zqNwLHaMOAy0/jeoltwqyGYTlrye0A7VrrEW +jM/oSx34uhU57sKojPMIsnUvMgPbBvhNy/K/rft9MdWJDMcB75BwAItLLJKPFZ+qCaK 6VGDMiCAgNx7sOXQPeweLvDJd2WnTQUYsN+txILdJv/d3eGEHJhQaH5NYbzTydaXiN4M 1Qeg== X-Gm-Message-State: AOJu0YxFYejJpAIrVp/ZxIgBmemDda/NGkfUylfKXAu9L+ViqJBQPf0i X8tfBHgU1aHs7yfe8pNV7rAACimA/8MAK6vlYLTacMfx7R5YHUM3 X-Google-Smtp-Source: AGHT+IEWBN5cba+8ai9Mf4SyWesi8R6/2iGW6WB4mijmfLw5IhkKP1bxFMPho1Mdmd2+8lrZcK8qemmKEH6xRmpL7eQ= X-Received: by 2002:ac2:5584:0:b0:50c:10b5:1744 with SMTP id v4-20020ac25584000000b0050c10b51744mr969102lfg.111.1702179905807; Sat, 09 Dec 2023 19:45:05 -0800 (PST) List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org MIME-Version: 1.0 From: Warner Losh Date: Sat, 9 Dec 2023 20:44:54 -0700 Message-ID: Subject: Drop READ(6) / WRITE(6) support in da/cd To: scsi@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a13fc9060c1fa4df" X-Spamd-Result: default: False [-2.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.937]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::134:from]; MLMMJ_DEST(0.00)[scsi@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[scsi@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4SnrP23PSrz3L7Q X-Spamd-Bar: -- --000000000000a13fc9060c1fa4df Content-Type: text/plain; charset="UTF-8" I'd like to move the default CDB size in the da driver from 6 to 10. I'd like to make the driver never send READ6 commands (and likely the cd driver too). READ10 was an extended command in X.131-1986 (SCSI-1) required for any computer with self configuring software. It became mandatory in X.131-1994 (SCSI-2), 4 years before CAM entered the tree. It's been required for any device larger than 2GB. We purposely disable it on all USB and Firewire attached devices. Its support has been strongly encouraged as an alternative to READ6 since SBC (1997), with threats to withdraw READ6 once certain system software had been updated. It became obsolete in SBC-4 (2019).The days of minimizing a couple of bytes in the CDB have long since passed. We have a lot of quirks to disable these commands for both da and cd (as well as blanket disabling them for RBC devices). In short, it's a lot of hassle that we go to, and there doesn't seem like there's any benefit. A quick search of the mailing list shows the overwhelming majority of traffic are the problems it causes. I can find no place where the benefits of using it are explained (though maybe I missed something). So, I'd like to remove it before 15, making 10 the minimum CDB for I/O commands (READ/WRITE,etc). we'll still send 6 byte commands for TEST UNIT READ, MODE SENSE, etc. While, as luck would have it, I still have some 100MB and 200MB drives, I have not HBA that has the right kind of interconnect to read them, so I can't even experiment to see if these old MAXTOR drives from the 80s support READ10... Comments? Warner --000000000000a13fc9060c1fa4df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to move the default CDB size in the da d= river from 6 to 10. I'd like to make the driver never send READ6 comman= ds (and likely the cd driver too).

READ10 was an e= xtended command in X.131-1986 (SCSI-1) required for any computer with self = configuring software. It became mandatory in X.131-1994 (SCSI-2), 4 years b= efore CAM entered the tree. It's been required for any device larger th= an 2GB. We purposely disable it on all USB and Firewire attached devices. I= ts support has been strongly encouraged as an alternative to READ6 since SB= C (1997), with threats to withdraw READ6 once certain system software had b= een updated. It became obsolete in SBC-4 (2019).The days of minimizing a co= uple of bytes in the CDB have long since passed. We have a lot of quirks to= disable these commands for both da and cd (as well as blanket disabling th= em for RBC devices).

In short, it's a lot of h= assle that we go to, and there doesn't seem like there's any benefi= t. A quick search of the mailing list shows the overwhelming majority of tr= affic are the problems it causes. I can find no place where the benefits of= using it are explained (though maybe I missed something).
So, I'd like to remove it before 15, making 10 the minimum= CDB for I/O commands (READ/WRITE,etc). we'll still send 6 byte command= s for TEST UNIT READ, MODE SENSE, etc.

While,= as luck would have it, I still have some 100MB and 200MB drives, I have no= t HBA that has the right kind of interconnect to read them, so I can't = even experiment to see if these old MAXTOR drives from the 80s support READ= 10...

Comments?

= Warner
--000000000000a13fc9060c1fa4df-- From nobody Sun Dec 10 18:28:26 2023 X-Original-To: scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SpD0S3j5Qz54CsD for ; Sun, 10 Dec 2023 18:28:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SpD0R5xdBz3Zt3 for ; Sun, 10 Dec 2023 18:28:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=TFtDRIcl; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::22e) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2c9c18e7990so50729161fa.2 for ; Sun, 10 Dec 2023 10:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1702232917; x=1702837717; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=/drvMOqw3S3LfxLNdSBPctfhCQ5sEm9nzsixg/J2NQU=; b=TFtDRIclqI4oHegkfrCBg6SXwRGt+WbhTS3kpMysjg5JxCx8iVqGH0tOzmr7fwNEEq VJUwl1ktyA4sWT0h9SU+3sBFGOusklELBNOZu0fn0kiluFNE/20rZczLTFyIlePtCexb EnCHpGdYgrvcq6prIecoWbrHAvg2aK5Sw0XZH1/lI9aPYFNQBhqSGcQgeZT3t6W8daYU XUfF/rUIo0/CjlPGq/Umh7q2CIQVO/o4k/zohY96X8ZOKToI5Y7EIc5SbNexWFnYq8xz oTMx0tlgF7WUkVQo+7djiLxOcZe1BsLZgPoiYJcYTaDMPuK6tVX/TaX/PGjKfIcdcLp7 Uy9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702232917; x=1702837717; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/drvMOqw3S3LfxLNdSBPctfhCQ5sEm9nzsixg/J2NQU=; b=N/bO9f0VuKvIVna0mWXz1hIA3ZDHmsfqP8sOKDMyi2ekcOVEaRXv+R7aUJjL9Gn06A Nz4GnoVogk1eE3DxvdX9s3pIi5MjhLeOtpQuUqIu/TkvHINaVGZOQNyBJ1+tYc6IR+PG h9jxSj4/kL/wtl+1u3H9zcgTzotoh9akznB4T2Ejq4+Mf2Y/b/FqJBgG/BjLXh+/OWWK +N2NUTZHuUt2OWIoW805y6Ed7xxMOft1xRTbg28joquDTN8AvcLVnMBmsT12vQNh+dtB orU6IH9HKKmlGL+UM7/vcL3rToHM07SCvAndAq1n1KAh6SGUd7n+o+CKDM+oOJuoK1aD lE1Q== X-Gm-Message-State: AOJu0YxobWZjeinCsTkNS7YFGrOynryUoIaXbVFmolhKwm+SGRE40IlQ RpUzo5RBlPijqh0UKULTAf31yKmYsXMWOS7vCrv3wVVAj8rBwD6A X-Google-Smtp-Source: AGHT+IEoc/DrYtXITJ5nkMAUYUgbtBdttISF3euMZ9NRXTy5nykqTQveiWlCD8uVZu6iluRLnxiCA22yHIiSQgwoDdE= X-Received: by 2002:a05:651c:987:b0:2cc:207f:33a5 with SMTP id b7-20020a05651c098700b002cc207f33a5mr359048ljq.33.1702232917453; Sun, 10 Dec 2023 10:28:37 -0800 (PST) List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 10 Dec 2023 11:28:26 -0700 Message-ID: Subject: Re: Drop READ(6) / WRITE(6) support in da/cd To: scsi@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005ebb69060c2bfc65" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22e:from]; MLMMJ_DEST(0.00)[scsi@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[scsi@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4SpD0R5xdBz3Zt3 X-Spamd-Bar: -- --0000000000005ebb69060c2bfc65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 9, 2023 at 8:44=E2=80=AFPM Warner Losh wrote: > I'd like to move the default CDB size in the da driver from 6 to 10. I'd > like to make the driver never send READ6 commands (and likely the cd driv= er > too). > > READ10 was an extended command in X.131-1986 (SCSI-1) required for any > computer with self configuring software. It became mandatory in X.131-199= 4 > (SCSI-2), 4 years before CAM entered the tree. It's been required for any > device larger than 2GB. We purposely disable it on all USB and Firewire > attached devices. Its support has been strongly encouraged as an > alternative to READ6 since SBC (1997), with threats to withdraw READ6 onc= e > certain system software had been updated. It became obsolete in SBC-4 > (2019).The days of minimizing a couple of bytes in the CDB have long sinc= e > passed. We have a lot of quirks to disable these commands for both da and > cd (as well as blanket disabling them for RBC devices). > > In short, it's a lot of hassle that we go to, and there doesn't seem like > there's any benefit. A quick search of the mailing list shows the > overwhelming majority of traffic are the problems it causes. I can find n= o > place where the benefits of using it are explained (though maybe I missed > something). > > So, I'd like to remove it before 15, making 10 the minimum CDB for I/O > commands (READ/WRITE,etc). we'll still send 6 byte commands for TEST UNIT > READ, MODE SENSE, etc. > > While, as luck would have it, I still have some 100MB and 200MB drives, I > have not HBA that has the right kind of interconnect to read them, so I > can't even experiment to see if these old MAXTOR drives from the 80s > support READ10... > Some additional points after looking at some old manuals on bitsavers and reading other people's code: 1) Linux uses READ10 or bigger by default (though they still have code to allow READ6/WRITE6). 2) OpenBSD sends READ6/WRITE6 only to SCSI1 devices (and omits atapi and usb devices) 3) NetBSD will send read6/write6 commands, but provides overrides for SIMs to disable them (much like we do for USB and Firewire). 4) A survey of half a dozen manuals for old SCSI drives show that Seagate, Maxtor and Quantum drives larger than about 30MB support READ10/WRITE10 (called Read extended in their manuals). Only an Apple 20MB external drive from 1985 didn't support it. Sony SCSI CD from 1989 supports READ10. All of the above suggests that we can just remove support entirely and nobody would notice... SCSI disks were in the 75MB-200MB range when FreeBSD 1.0 came out, and were mostly > 500MB by the time CAM went into the tree. SCSI CDROMs weren't exactly rare, but they weren't super common and have largely disappeared except as USB attached devices where we disable READ6 already anyway. I noticed this while testing a new I/O tracing program I've written... > Comments? > > Warner > --0000000000005ebb69060c2bfc65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 9, 2023 at 8:44=E2=80=AFP= M Warner Losh <imp@bsdimp.com> = wrote:
I'd like to move the default CDB size in the da driver fr= om 6 to 10. I'd like to make the driver never send READ6 commands (and = likely the cd driver too).

READ10 was an extended = command in X.131-1986 (SCSI-1) required for any computer with self configur= ing software. It became mandatory in X.131-1994 (SCSI-2), 4 years before CA= M entered the tree. It's been required for any device larger than 2GB. = We purposely disable it on all USB and Firewire attached devices. Its suppo= rt has been strongly encouraged as an alternative to READ6 since SBC (1997)= , with threats to withdraw READ6 once certain system software had been upda= ted. It became obsolete in SBC-4 (2019).The days of minimizing a couple of = bytes in the CDB have long since passed. We have a lot of quirks to disable= these commands for both da and cd (as well as blanket disabling them for R= BC devices).

In short, it's a lot of hassle th= at we go to, and there doesn't seem like there's any benefit. A qui= ck search of the mailing list shows the overwhelming majority of traffic ar= e the problems it causes. I can find no place where the benefits of using i= t are explained (though maybe I missed something).

=
So, I'd like to remove it before 15, making 10 the minimum CDB for= I/O commands (READ/WRITE,etc). we'll still send 6 byte commands for TE= ST UNIT READ, MODE SENSE, etc.

While, as luck= would have it, I still have some 100MB and 200MB drives, I have not HBA th= at has the right kind of interconnect to read them, so I can't even exp= eriment to see if these old MAXTOR drives from the 80s support READ10...

Some additional points after = looking at some old manuals on bitsavers and reading other people's
code:
1) Linux uses READ10 or bigger by default (though th= ey still have code to allow READ6/WRITE6).
2) OpenBSD sends READ6= /WRITE6 only to SCSI1 devices (and omits atapi and usb devices)
3= ) NetBSD will send read6/write6 commands, but provides overrides for SIMs t= o disable them
=C2=A0=C2=A0 (much like we do for USB and Firewire= ).
4) A survey of half a dozen manuals for old SCSI drives show t= hat Seagate, Maxtor and
=C2=A0=C2=A0 Quantum drives larger than a= bout 30MB support READ10/WRITE10 (called Read extended
=C2=A0=C2= =A0 in their manuals). Only an Apple 20MB external drive from 1985 didn'= ;t support it. Sony SCSI
=C2=A0 CD from 1989 supports READ10.
=

All of the above suggests that we can just remove= support entirely and nobody would notice...
SCSI disks were in t= he 75MB-200MB range when FreeBSD 1.0 came out, and were mostly
&g= t; 500MB by the time CAM went into the tree. SCSI CDROMs weren't exactl= y rare, but they
weren't super common and have largely disapp= eared except=C2=A0 as USB attached devices where
we disable READ6= already anyway.

I noticed this while testing a ne= w I/O tracing program I've written...
=C2=A0
Comments?

Warner
--0000000000005ebb69060c2bfc65--