On Sun, 1 Dec 2019 03:52:50 +0100 Tomasz CEDRO <to...@cedro.info> wrote:
> On Sun, Dec 1, 2019 at 3:03 AM Anatoly wrote: > > I've had a problem in the past with one of the first 32GB pendrives. > > Not quite similar problem, but may it be buggy RAM cache > > implementation too? What if: > > - Write sector(s) > > - usbconfig -d <your_bus>.<your_dev> power_off > > - usbconfig -d <your_bus>.<your_dev> power_on > > - Read and compare. > > > > As you saying some writes was succeful, some not. May it > > depend not on source of that bytes or their content, but on time passed > > between write and read? > > > > It turns out that Transcend pendrive I've got in 2010 had RAM cache > > (didn't remember exact cache size I measured out, as I remember > > something around 128K-512K), and all writes was cached. This amazingly > > speeds up random R/W fs operations in comparation with similar > > pendrives of those years, but I constantly losing the data and getting > > fs corrupted when used it with OSes that do not "power_off" or > > "suspend" that drive before I pull of it out of the socket. > > The first pendrive is physically smaller Kingston slower and more > expensive. The second Kingston (the one with write problems) is > physically bigger 30% cheaper and a bit faster (50% read, 10% write, > but not as advertised 2x read, 4x write). If its cheaper and faster > then Kingston is bullshitting their clients. Also one of their workers > admitted that they have various vendors of flash controllers and > different firmware among them. so their products looks more like a > lottery. Not cool. > > Thank you Anatoly! It looks then like a pendrive faulty tricky design > to fool users with exaggerated read/w/rite speeds. > The geom code protects certain parts of the data area on the drive, in particular GPT/MBR areas, unless ``sysctl kern.geom.debugflags=16'' is run beforehand. One can see this in many places in the geom code. I always set this sysctl when I know I'm going to overwrite the first sectors of a drive. -- Gary Jennejohn _______________________________________________ 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"