From owner-freebsd-usb@freebsd.org Mon May 25 09:40:53 2020 Return-Path: Delivered-To: freebsd-usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8A4CD2FA431 for ; Mon, 25 May 2020 09:40:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49VsXj3D95z4gpx for ; Mon, 25 May 2020 09:40:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6E9202FA5AC; Mon, 25 May 2020 09:40:53 +0000 (UTC) Delivered-To: usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E5D32FA377 for ; Mon, 25 May 2020 09:40:53 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49VsXj2N90z4h8c for ; Mon, 25 May 2020 09:40:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 3459C10385 for ; Mon, 25 May 2020 09:40:53 +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 04P9erNa058847 for ; Mon, 25 May 2020 09:40:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04P9erLw058846 for usb@FreeBSD.org; Mon, 25 May 2020 09:40:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 244356] Writing to a USB 3.0 stick is very slow Date: Mon, 25 May 2020 09:40:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: needs-qa, performance X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olivier.freebsd@free.fr X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 09:40:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244356 --- Comment #85 from Olivier Certner --- (In reply to Gary Jennejohn from comment #76) Yes. You're comparing write with read performance, and indeed there is a significant difference. Personally, I'm more concerned with write performan= ce, and especially to some UFS filesystem. I have always assumed that read performance would be better than write's, that's why I'm concentrating on writes, another reason being that, in my use case, the stick is most of the time entirely overwritten when written to, whereas when read (much more oft= en), it is only so partially (usually a small to very small part). And the probl= em is that write performance is quite low, meaning that it can take 8 hours to fill a 64GB stick with the initial performance I reported (~2.5MiB/s). I remember getting better performance out of older USB 2.0 sticks than that (= even for not so small ones, e.g., 16GB; maybe a test would be in order). Indeed, I read that the erased state of flash is to have all bits set to 1. This describes internal mechanism, not necessarily external one. Usually, n= ew sticks come formatted, so the "natural" state is probably not observable directly, even on a just-bought stick. 0 is so universally used as absence = of data that I would not be surprised if some controller logic actually revers= es bit for storage, so that 0-filled sectors are in fact stored as 1-filled on= es. Provided of course that they are stored at all (these all filled sectors ma= y be handled differently by the firmware, I don't know). The fact that zeroing t= he whole stick before access indeed increases performance could be a consequen= ce of that. I'm quite interested in the result of your tests, i.e., the bandwidth comparison before and after having overwritten the stick with 0xFF. If bit-reversal is indeed present, and there is no sophisticated management mechanism for "empty" cells, then your test could actually show no performa= nce improvement. If it does, then something else is going on. In any case, we'll have learned something. --=20 You are receiving this mail because: You are the assignee for the bug.=