Hi all, I ran into this while trying to use geli to encrypt an external usb-2 hard drive. It appears that sometimes the media size reported by umass is one sector too big. For example: umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <WDC WD18 00JB-00DUA0 65.1> Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 171705MB (351651889 512 byte sectors: 255H 63S/T 21889C) # dd if=/dev/zero of=/dev/da0 oseek=351651888 count=1 dd: /dev/da0: Input/output error 1+0 records in 0+0 records out 0 bytes transferred in 0.002951 secs (0 bytes/sec) # dd if=/dev/zero of=/dev/da0 oseek=351651887 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000982 secs (521360 bytes/sec) This is with a "high speed, power 100 mA, config 1, Mass Storage Device(0x3507), Prolific Technology Inc.(0x067b), rev 1.00" enclosure. I tested with two USB flash memory devices and those seem to report the correct size. I'm currently rebuilding a kernel with USB_DEBUG to see if it's specific to a certain protocol and try to figure out if it's a bug in one of them or if the enclosure is lying. Has anyone run into this before? Craig
Craig Boston wrote:> Hi all, I ran into this while trying to use geli to encrypt an external > usb-2 hard drive. It appears that sometimes the media size reported by > umass is one sector too big. For example: > > umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: <WDC WD18 00JB-00DUA0 65.1> Fixed Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 171705MB (351651889 512 byte sectors: 255H 63S/T 21889C) > > # dd if=/dev/zero of=/dev/da0 oseek=351651888 count=1 > dd: /dev/da0: Input/output error > 1+0 records in > 0+0 records out > 0 bytes transferred in 0.002951 secs (0 bytes/sec) > > # dd if=/dev/zero of=/dev/da0 oseek=351651887 count=1 > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.000982 secs (521360 bytes/sec) > > This is with a "high speed, power 100 mA, config 1, Mass Storage > Device(0x3507), Prolific Technology Inc.(0x067b), rev 1.00" enclosure. > I tested with two USB flash memory devices and those seem to report the > correct size. > > I'm currently rebuilding a kernel with USB_DEBUG to see if it's specific > to a certain protocol and try to figure out if it's a bug in one of them > or if the enclosure is lying. Has anyone run into this before? > > CraigFixed in 7-CURRENT. Contact Warner Losh to make sure that your device is quirked appropriately. Scott
Artem Kuchin wrote:> I used unixbenchmark for measure overall perfomance of three machines of > different generations and with different OS versions. See for your self and > compare results with machine cost. > Hope this will be usefull for someone.Several things: a) It looks like your message was weirdly truncated - whole "rectangles" of text are missing from the results on the right-hand-side. Maybe you copied it through Excel? b) I submitted a patch for unixbench than enables execl benchmark on amd64, it should be in the ports tree by now. c) It would be interesting for the general discussion if you could install a recent server-like version of Linux (e.g. CentOS, SuSE, Debian) on one of the machines you did your benchmarks on to compare results :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070306/cd95fb2f/signature.pgp
----- Original Message ----- From: "Fluffles" <etc@fluffles.net> To: "Artem Kuchin" <matrix@itlegion.ru> Sent: Wednesday, March 07, 2007 11:35 PM Subject: Re: Some Unix benchmarks for those who are interesed> Artem Kuchin wrote: >>>> Artem Kuchin wrote: >>>> Hmm. what kind of HDD, RAID or whatever are you using? >>>> My raid pretty much sucks. It is build it on the intel motherboard >>>> LSI Megaraid. But i still get 81Mb/sec when doing >>>> dd if=/dev/ar0 of=/dev/null bs=1M >>>> >>>> How much do you get on this? >>> >>> geom_mirror on 2 desktop SATA drives, but the results of dd are >>> pretty low: >>> >>> # dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 >>> 1000+0 records in >>> 1000+0 records out >>> 1048576000 bytes transferred in 17.817686 secs (58850290 bytes/sec) >>> >>> As you can see, results with a single drive are better: >>> >>> # dd if=/dev/ad4 of=/dev/null bs=1m count=1000 >>> 1000+0 records in >>> 1000+0 records out >>> 1048576000 bytes transferred in 16.219518 secs (64649023 bytes/sec) >> >> How is it possible that you get 2x file copy perfomance ? What's the >> matter?! > > If you use dd on the raw device (meaning no UFS/VFS) there is no > read-ahead. This means that the following DD-command will give lower STR > read than the second: > > no read-ahead: > dd if=/dev/mirror/data of=/dev/null bs=1m count=1000 > read-ahead and multiple I/O queue depth: > dd if=/mounted/mirror/volume of=/dev/null bs=1m count=1000 > > You can test read STR best with bonnie (see > /usr/ports/benchmarks/bonnie); or just with DD on a mounted volume. You > should mount with -o noatime to avoid useless writes during reading, or > use soft updates to prevent meta data from taking it's toll on I/O > performance. >Totall disagree. On the following reasons: 1) Read ahead is simply useless when stream-reading (sequential) 1GB of data 2) atime is NOT updated when using dd on any device, atime is related to file/inode operations which are not performed by dd 3) soft update are also useless (no bad, no good) for long sequential read basically, long sequatial reads/write ignore anything but real drive speed (plate on the spindle) if they are performed long enough. I think that 2 times differences is reallty related to seek times. But on the other hand i am sure my HDD have very good seek times. I'll have a chance to check it all on friday. -- Artem