https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244356
--- Comment #85 from Olivier Certner <olivier.free...@free.fr> --- (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 performance, 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 often), it is only so partially (usually a small to very small part). And the problem 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, new 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 reverses bit for storage, so that 0-filled sectors are in fact stored as 1-filled ones. Provided of course that they are stored at all (these all filled sectors may be handled differently by the firmware, I don't know). The fact that zeroing the whole stick before access indeed increases performance could be a consequence 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 performance improvement. If it does, then something else is going on. In any case, we'll have learned something. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
