Re: writing to usb very slow
# mount -o async /dev/sd1a /mnt # date && cp -r TEST/ /mnt && umount /mnt && date Wed Jan 20 00:17:54 CET 2010 Wed Jan 20 00:33:35 CET 2010 2010/1/20 David Vasek : > On Tue, 19 Jan 2010, T. Tofus von Blisstein wrote: > >> Hello David, >> >> thanks. > > You're welcome. > >> # mount /dev/sd1a /mnt >> # date && cp -r TEST/ /mnt && umount /mnt && date >> Tue Jan 19 23:11:27 CET 2010 >> Tue Jan 19 23:29:12 CET 2010 >> >> So it's reduced a lot, but still it is much slower than... sorry guys, >> the penguin. >> >> Still, from 50 minutes to 18 to copy 256M is a significant improvement > > Try using "softdep" option for mount, possibly even the "async" option, if > you like the risk, otherwise you are comparing two completely different > modes of filesystem operation. > > Regards, > David
Re: writing to usb very slow
sorry about that, but I also have noticed this problem with external usb drives I don't have any kind of test to report yet, though 2010/1/19 Jacob Meuser : > On Tue, Jan 19, 2010 at 10:54:16PM +0100, T. Tofus von Blisstein wrote: > >> The point is that I have many huge USB drives which I would not like >> to throw away just like that > > this thread is really confusing. is the subject "flash/memory sticks", > or "any USB storage"? > > it seems to me the only thing that is slow is flash/memory sticks, or > maybe I'm missing something? > > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org
Re: writing to usb very slow
Hello David, thanks. # date && dd if=/dev/rsd1c bs=64k count=1k of=/dev/null && date Tue Jan 19 23:02:59 CET 2010 1024+0 records in 1024+0 records out 67108864 bytes transferred in 4.130 secs (16249108 bytes/sec) Tue Jan 19 23:03:03 CET 2010 # dd if=/dev/zero bs=64k count=1k of=/dev/rsd1c 1024+0 records in 1024+0 records out 67108864 bytes transferred in 15.053 secs (4458089 bytes/sec) Now I reformatted the drive to 4.4BSD disklabel -E /dev/rsd1c allocate all for partition a newfs /dev/rsd1c And run again my "personal" test... # tail -f /var/log/messages Jan 19 22:11:20 hux /bsd: sd1: 983MB, 512 bytes/sec, 2015231 sec total Jan 19 23:11:02 hux /bsd: sd1 detached Jan 19 23:11:02 hux /bsd: scsibus1 detached Jan 19 23:11:02 hux /bsd: umass0 detached Jan 19 23:11:05 hux /bsd: umass0 at uhub1 Jan 19 23:11:05 hux /bsd: port 2 configuration 1 interface 0 "PRETEC Technology USB Mass Storage Device" rev 2.00/1.00 addr 2 Jan 19 23:11:05 hux /bsd: umass0: using SCSI over Bulk-Only Jan 19 23:11:05 hux /bsd: scsibus1 at umass0: 2 targets, initiator 0 Jan 19 23:11:05 hux /bsd: sd1 at scsibus1 targ 1 lun 0: <-Pretec, 01GB, 2.00> SCSI2 0/direct removable Jan 19 23:11:05 hux /bsd: sd1: 983MB, 512 bytes/sec, 2015231 sec total ^C # mount /dev/sd1a /mnt # date && cp -r TEST/ /mnt && umount /mnt && date Tue Jan 19 23:11:27 CET 2010 Tue Jan 19 23:29:12 CET 2010 So it's reduced a lot, but still it is much slower than... sorry guys, the penguin. Still, from 50 minutes to 18 to copy 256M is a significant improvement I think the penguin takes some 2 minutes for that... but I can live with it Since I only do a _full_ backup once every 5 months or so and I have a script using rsync, I only have to transfer some 18M or so every time I do a normal backup Thanks, T. 2010/1/19 David Vasek : > On Tue, 19 Jan 2010, T. Tofus von Blisstein wrote: > >> Hello, >> >> this is an example. Attached is a 1GB (fat!) usb memory stick. It took >> 40 minutes to copy 285M. >> >> This one was >> >> Jan 19 21:18:04 hux /bsd: umass0: using SCSI over Bulk-Only >> Jan 19 21:18:04 hux /bsd: scsibus1 at umass0: 2 targets, initiator 0 >> Jan 19 21:18:04 hux /bsd: sd1 at scsibus1 targ 1 lun 0: <-Pretec, >> 01GB, 2.00> SCSI2 0/direct removable >> Jan 19 21:18:04 hux /bsd: sd1: 983MB, 512 bytes/sec, 2015231 sec total >> >> I will repeat the test with all other ports now. > > There shouldn't be any difference among individual USB ports. > > First, try this: > > # dd if=/dev/rsd1c bs=64k count=1k of=/dev/null > > (or just hit ^C if it takes too long) and see what the reading speed of the > _device_ is. If you don't have any data on the device and if you are willing > to recreate the MBR and filesystem there, you can also test the writing > speed: > > # dd if=/dev/zero bs=64k count=1k of=/dev/rsd1c > > Otherewise you are also measuring the filesystem performance and such. For > some reason (which is unknown to me), "foreign" filesystems, such as ext2fs > and msdos, are quite slow on OpenBSD, both for reading and for writing. The > CPU is not the bottleneck in operations on these filesystems. > > Regards, > David > -- Pau
Re: writing to usb very slow
indeed... Tue Jan 19 22:11:38 CET 2010 Tue Jan 19 22:51:50 CET 2010 I will try your test now The point is that I have many huge USB drives which I would not like to throw away just like that I cannot afford looking for new usb drives which are fine on obsd. I would like to understand what is going on (at least within my limits of understanding!) Thanks T. 2010/1/19 David Vasek : > On Tue, 19 Jan 2010, T. Tofus von Blisstein wrote: > >> Hello, >> >> this is an example. Attached is a 1GB (fat!) usb memory stick. It took >> 40 minutes to copy 285M. >> >> This one was >> >> Jan 19 21:18:04 hux /bsd: umass0: using SCSI over Bulk-Only >> Jan 19 21:18:04 hux /bsd: scsibus1 at umass0: 2 targets, initiator 0 >> Jan 19 21:18:04 hux /bsd: sd1 at scsibus1 targ 1 lun 0: <-Pretec, >> 01GB, 2.00> SCSI2 0/direct removable >> Jan 19 21:18:04 hux /bsd: sd1: 983MB, 512 bytes/sec, 2015231 sec total >> >> I will repeat the test with all other ports now. > > There shouldn't be any difference among individual USB ports. > > First, try this: > > # dd if=/dev/rsd1c bs=64k count=1k of=/dev/null > > (or just hit ^C if it takes too long) and see what the reading speed of the > _device_ is. If you don't have any data on the device and if you are willing > to recreate the MBR and filesystem there, you can also test the writing > speed: > > # dd if=/dev/zero bs=64k count=1k of=/dev/rsd1c > > Otherewise you are also measuring the filesystem performance and such. For > some reason (which is unknown to me), "foreign" filesystems, such as ext2fs > and msdos, are quite slow on OpenBSD, both for reading and for writing. The > CPU is not the bottleneck in operations on these filesystems. > > Regards, > David > -- Pau
Re: writing to usb very slow
which filesystem are you using on that device? T. 2010/1/19 FRLinux : > On Tue, Jan 19, 2010 at 9:10 PM, T. Tofus von Blisstein > wrote: >> this is an example. Attached is a 1GB (fat!) usb memory stick. It took >> 40 minutes to copy 285M. > > Mmmh, clearly your key. Just did a test on my OpenBSD laptop (Samsung > Q35) with that key connected: > > umass0 at uhub0 port 1 configuration 1 interface 0 "Corsair VoyagerGT" > rev 2.00/11.00 addr 2 > umass0: using SCSI over Bulk-Only > scsibus1 at umass0: 2 targets, initiator 0 > sd0 at scsibus1 targ 1 lun 0: SCSI0 > 0/direct removable > > Writing the same sized file took me 1m10s. This is using your test and > with a 285M file. > > Steph > -- Pau
Re: writing to usb very slow
Hello, this is an example. Attached is a 1GB (fat!) usb memory stick. It took 40 minutes to copy 285M. This one was Jan 19 21:18:04 hux /bsd: umass0: using SCSI over Bulk-Only Jan 19 21:18:04 hux /bsd: scsibus1 at umass0: 2 targets, initiator 0 Jan 19 21:18:04 hux /bsd: sd1 at scsibus1 targ 1 lun 0: <-Pretec, 01GB, 2.00> SCSI2 0/direct removable Jan 19 21:18:04 hux /bsd: sd1: 983MB, 512 bytes/sec, 2015231 sec total I will repeat the test with all other ports now. Thanks again T. # du -hs TEST/ 285MTEST/ # date && cp -r TEST/ /mnt && umount /mnt && date Tue Jan 19 21:20:01 CET 2010 Tue Jan 19 22:00:18 CET 2010 # usbdevs -v Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: high speed, power 80 mA, config 1, USB Mass Storage Device(0xba63), PRETEC 00, iSerialNumber 01AE000823 port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 addr 2: full speed, power 100 mA, config 1, Fingerprint Sensor(0x2810), AuthenTec(0 port 2 powered Controller /dev/usb4: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered Controller /dev/usb5: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 port 1 powered port 2 powered 2010/1/19 Robert : > Ted Unangst wrote: >> >> Plug it in. The kernel tells you. >> > > usbdevs -v also helps > > regards, > Robert > > -- Pau
Re: writing to usb very slow
Hello Donald, well, I cannot tell the same here. I still think it must be related to that usb 1.0 being reported in dmesg usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 usb2 at uhci0: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 "Intel UHCI root hub" rev 1.00/1.00 addr 1 I would like to find out which is the one which is reported as 2.0 and I only have three USB ports... anyway, thanks to all of you for your help T. 2010/1/19 Donald Allen : > Sounds like you are already on the right track, courtesy Peter > Hansteen, so I'll simply support the direction you are going by > telling you that I back up my systems (with a home-brew scheme that > uses a combination of rsync and tar) to 7200 rpm SATA drives in USB > shoeboxes with ext2 filesystems and have done so for years running > Linux and for the last 10 months or so running OpenBSD on the same set > of hardware (an assortment of Thinkpads, a Lenovo workstation, and a > cheap HP desktop). I've had no performance problems with OpenBSD doing > backups to these drives and therefore I haven't any measurements to > quote. But I'd notice it if OpenBSD were a factor of 5 slower; it > isn't. > > /Don Allen > -- Pau
writing to usb very slow
Hello, I have noticed that writing to a usb drive is "slow". What does "slow" mean? It means that compared to other OS's. Which OS's? Yes, it hurts: the penguin. Information: The external drive has been formated as ext2, so that I can mount it with obsd and the penguin Copying some 72G takes ~ 2hours on the penguin and some... 10 hours or more This is obsd -current snapshot of 12 Jan, i386 Actually it's even worse I start the copying of those 72G before I go to bed Then the system freezes ctrl+alt+f1 to get a console does nothing ctrl + alt + backspace does nothing Sounds like an APCI problem? It feels like USB 1 or worse _and_ the system freezes You can of course blame the device, but I have had the same speed problem on a number of devices You can now stone me, call me stupid, tell me that I have stated that linux gives free blowjobs, that I am a dumbass etc etc etc... it's fine, go for it but after that, please try to copy to an extermal drive some 3G with linux and obsd and tell me the difference. I am all against linux, I love obsd, I have obsd as my main production system, I buy the CDs at each release ... and I know this is misc and not exactly the most friendly place of the world I am simply asking: Has anybody else noticed this or am I the only one on the face of the world with this problem? Any (positive, polite) comment will be very much appreciated. T.
installboot: broken MBR
Hello, I have linux and openbsd installed on a single drive. Linuxy fdisk shows Device Boot Start End Blocks Id System /dev/sda1 1 24017 1929165215 Extended Partition 1 does not end on cylinder boundary. /dev/sda2 * 24018 3040151279480 a6 OpenBSD /dev/sda5 1 127 1020064+ 83 Linux /dev/sda62708 23506 167067936 83 Linux /dev/sda7 128270720723818+ 83 Linux /dev/sda8 23507 24017 4104576 82 Linux swap / Solaris The linuxy menu.lst shows titleOpenBSD rootnoverify (hd0,1) savedefault makeactive chainloader+1 After a clean install, the openbsd installer says: "installboot: broken MBR" Then GRUB protests when booting openbsd with error 13: "Invalid or unsupported executable format" I have seen the "does not end on cylinder boundary." warning of fdisk a number of times in the past, and yet I was able to boot in openbsd. I think it must be a linux bogus. Any help will be appreciated. T.
