Re: RAID5 on athlon64 machines
Theoretically the sequential write rate should be same or higher than the sequential read rate. Given an N+1 disk Seq write rate for the whole RAID5 array will always be lower than the write rate for it's single disk. You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? The parity blocks are not read on data reads, since this would be unnecessary overhead and would diminish performance. The parity blocks are read, however, when a read of a data sector results in a cyclic redundancy check (CRC) error. You can only do so if you know the array is consistent. If the system crashed there is no such guarantee. So you either have to rebuild the whole array to get to a consistent state or do a parity check. If you don't check parity and you have an inconsistent array, you can have a silent error (the data may be trashed but you don't know that). But if you use RAM without parity or ECC, you probably already don't care about such errors. IMO, RAID does not protect against system crashes - all it does is provide performance increase and/or some protection against hardware failure (which will be detected with extremely high probability) enabling the admin to restore some data. p.S.: this is not hackers@ discussion. Timestamp: 0x43EEF1C0 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/60163
Norikatsu Shigemura wrote: I heard from Chiharu Shibata [EMAIL PROTECTED] about kern/60163. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60163 (He knew that this pr was closed, recently) I cannot believe sos's close reason. ** The most significant problem is Cannot mount CD-EXTRA multisession cd.. No related /dev/acdXtY. ** If there are no reason expect sos' close reason, the patch should be committed. How about this? Uhm, why the fuzz about this now, this PR was closed on Mon Sep 6 11:40:13 GMT 2004 according to logs. However on the patch involved: setting the blocksize for the /dev/acd0 device depending on blocksize of any track is just as wrong as setting it to the size of the first track, it just fails in different ways. So the right way to do this on multitrack media, is to mount any track as /dev/acdNtY which will set the blocksize correctly for that track. Thats why the PR was closed as stated in the PR logs... So, if we should rehash this again I'll need more details on what it is that fails exactly doing what, CD layouts etc etc... -Søren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
On Sun, 12 Feb 2006, [EMAIL PROTECTED] wrote: [missing attribution] You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? Easy, you can write simultaneously to more than one drive, assuming the drive was the bottleneck in the first place. -- David Taylor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
On Sun, 12 Feb 2006, [EMAIL PROTECTED] wrote: [missing attribution] You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? Easy, you can write simultaneously to more than one drive, assuming the drive was the bottleneck in the first place. Sorry, my mistake. Confused some RAID levels... Of course, with RAID5, the data block will be split (not mirrored) across several drives (plus a parity block will be added). Perhaps the original poster (bitblocks.com!bakul) may want to resend his question? Since he's experiencing performance problems with gvinum, this could very well be a hackers@ question; some more details may be needed, though. I apologize for all the confusion created here. Timestamp: 0x43EF2B47 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic Kernel Dump to umass device?
In message [EMAIL PROTECTED], Nate Nielsen writes: Thanks, that helps. It works nicely with a uhci USB controller. However when the ohci driver is in use, we crash somewhere in usb_transfer_complete. I'll look into this further. You could try updating to the latest 6-stable usb code, which might possibly help the ohci case. There were a number of quite severe ohci issues fixed since 6.0-release that might trigger more easily when using polling. In particular, these revisions may be of interest: ohci.c 1.154.2.1 ohcivar.h 1.40.2.1 usbdi.c 1.91.2.1 Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/60163
Chiharu Shibata wrote: [snip] So, if we should rehash this again I'll need more details on what it is that fails exactly doing what, CD layouts etc etc... This is a sample DISC's rayout. Starting track = 1, ending track = 13, TOC size = 114 bytes track start duration block length type - 1 0:02.00 4:09.25 0 18550 audio 2 4:09.25 4:28.22 18550 19972 audio 3 8:35.47 4:00.48 38522 17898 audio 4 12:34.20 5:56.37 56420 26587 audio 5 18:28.57 4:59.45 83007 22320 audio 6 23:26.27 5:13.15 105327 23340 audio 7 28:37.42 0:21.58 1286671483 audio 8 28:57.25 3:51.72 130150 17247 audio 9 32:47.22 5:02.10 147397 22510 audio 10 37:47.32 4:23.30 169907 19605 audio 11 42:08.62 4:41.70 189512 20995 audio 12 46:48.57 3:28.27 210507 15477 audio 13 50:15.09 4:36.37 225984 20587 data 170 54:49.46 - 246571 - - To mount this DISC, your opinion is... (1) at first, try cdcontrol -f /dev/acd0c info to make sure where track is data area. (2) type mount_cd9660 -o rdonly /dev/acd0t13 /cdrom. Is this right? Yeah that used to work at least, if not it needs fixing of course.. Any chance you could put up a mirror of that disk image so I could burn me one exactly like it to test with please ? the one I had here of the sort seems to have gone amiss, making testing a pain.. -Søren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Moused
Hi, i patched ums.c to support up to 31 mouse buttons (changed button type to int and set MAX_BUTTONS to 31) so far the patch is working. Now i have a problem with the moused it ignores buttons 6 and 7 and 15 of my Logitech MediaPlay mouse. And i cant find the reason, somehow it isnt handled by the moused ... all other buttons work and moused gets the buttons as input... iam a bit stuck... help would be great and i hope i wrote to the right list. -- Greetings, Christian Holzberger [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/60163
This is Chiharu Shibata. At Sun, 12 Feb 2006 10:36:20 JST, you wrote... Norikatsu Shigemura wrote: I heard from Chiharu Shibata [EMAIL PROTECTED] about kern/60163. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60163 (He knew that this pr was closed, recently) I cannot believe sos's close reason. ** The most significant problem is Cannot mount CD-EXTRA multisession cd.. No related /dev/acdXtY. ** If there are no reason expect sos' close reason, the patch should be committed. How about this? Uhm, why the fuzz about this now, this PR was closed on Mon Sep 6 11:40:13 GMT 2004 according to logs. GNATS system does not mail to me, because I'm a follower of this PR, not a originator. However on the patch involved: setting the blocksize for the /dev/acd0 device depending on blocksize of any track is just as wrong as setting it to the size of the first track, it just fails in different ways. So the right way to do this on multitrack media, is to mount any track as /dev/acdNtY which will set the blocksize correctly for that track. Thats why the PR was closed as stated in the PR logs... So, if we should rehash this again I'll need more details on what it is that fails exactly doing what, CD layouts etc etc... This is a sample DISC's rayout. Starting track = 1, ending track = 13, TOC size = 114 bytes track start duration block length type - 1 0:02.00 4:09.25 0 18550 audio 2 4:09.25 4:28.22 18550 19972 audio 3 8:35.47 4:00.48 38522 17898 audio 4 12:34.20 5:56.37 56420 26587 audio 5 18:28.57 4:59.45 83007 22320 audio 6 23:26.27 5:13.15 105327 23340 audio 7 28:37.42 0:21.58 1286671483 audio 8 28:57.25 3:51.72 130150 17247 audio 9 32:47.22 5:02.10 147397 22510 audio 10 37:47.32 4:23.30 169907 19605 audio 11 42:08.62 4:41.70 189512 20995 audio 12 46:48.57 3:28.27 210507 15477 audio 13 50:15.09 4:36.37 225984 20587 data 170 54:49.46 - 246571 - - To mount this DISC, your opinion is... (1) at first, try cdcontrol -f /dev/acd0c info to make sure where track is data area. (2) type mount_cd9660 -o rdonly /dev/acd0t13 /cdrom. Is this right? 1st Problem: I cannot mount this DISC though the procedure is completed. mount_cd9660: /dev/acd0t13: Invalid argument Did you succeed? In this case, the disklabel.d_secsize is still 2352, even if /dev/acdNtY is used. Does the hidden problem like this remain? 2nd Problem: It varies by the DISCs where the starting track of data area. Therefore, there is no way to write the entry of CD Extra DISC in /etc/fstab, and so on. Of course, my(and originator) patch can mount any CD Extra DISCs by /dev/acd0c. 3rd Problem: The originator says atapicam is OK. SCSI and ATAPICAM use /dev/cdYc, but ATA should use /dev/acdYtN to mount same CD Extra DISC. Don't you think this to be a strange specification? -- Chiharu Shibata[EMAIL PROTECTED]http://www32.ocn.ne.jp/~chi/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID5 on athlon64 machines
You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. How can the RAID5 write rate be higher for the whole array if not only it needs to write the data to all if its drives, but also compute and write a parity block? You write to all the disks at the same time. While the disks are busy writing you compute parity for the next stripe. In my case disk bw is 60MB/s. Memory bw is I thin 3GB/s. There ought to be plenty of bw and cpu for xor computing. IMO, RAID does not protect against system crashes - all it does is provide performance increase and/or some protection against hardware failure (which will be detected with extremely high probability) enabling the admin to restore some data. No it can't if you don't do the parity check on reads and a previous write to the stripe was incomplete due to system crash. You will happily deliver incorrect data to the user and he only knows *something* is wrong when his system crashes or program misbehaves or some binary data doesn't quite feel right or some text is garbled or some secondary bad effect. May be you need to use the same principle in your learning? Check your understanding by applying it and trying to extend it. Don't just believe what you read, cross-check it. Question the (so called) authority! The revolution will not be televised. Oops I think I have a scrambled brain block. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
UPEK TouchChip TFM/ESS Fingerprint BSP driver for FreeBSD
Hi all, I just thought that I let you know that UPEK [1] has released a native FreeBSD driver (binary only, closed source) for their fingerprint sensors. UPEK manufactures alot of fingerprint sensors, both built-in and standalone usb-readers. You can find them for example in several notebooks (IBM, Asus, Samsung, NEC, etc). There is a full list avaiable at http://www.upek.com/customer/pcnetworking/default.asp The driver itself is avaiable at http://www.upek.com/support/dl_freeBSD_bsp.asp and works as a module to the BioAPI [2] framework. I've also written a small quick-starting guide which covers the basics, it's avaiable at http://shapeshifter.se/articles/upek_touchchip_freebsd/ Please keep in mind that this is all quite new and should be treated as beta code. I should probably point out that I'm not affiliated with UPEK in any way except for providing their developers guidance in porting their Linux driver to FreeBSD. Also, I would like to thank the guys over at UPEK, especially Martin Konecny, for making this possible. Fredrik Lindberg [1] http://www.upek.com [2] http://www.bioapi.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
patchset-8-fix1 for 6.x release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patchset-8-fix1 for 6.x of unionfs. Patchset-8-fix1 for 6.x: For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p8-fix1.diff Changes in unionfs6-p8-fix1.diff - fixed 6.x build failure So sorry, unionfs6-p8 has a build failure unwittingly :( -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
