Re: Question about hard limits
On Sun, Apr 20, 2008 at 11:15 PM, Thomas Frell <[EMAIL PROTECTED]> wrote: > I run an icecast server which may grow into 10 000 listeners or more. > Are their any "gotchas" that I might need to patch change with sysctl? > I've changed kern.maxfiles and wondering if I could run out of TCP > sockets, or file descriptors, or something else I may have missed? > Aiming for high availability, so I am trying to be proactive and find > limits before clients find limits. > > Currently around 4 000 listeners hasn't posed any problems. Might look into max states. Older version of OBSD have a max of 10,000 (tunable via pf). -B
Question about hard limits
I run an icecast server which may grow into 10 000 listeners or more. Are their any "gotchas" that I might need to patch change with sysctl? I've changed kern.maxfiles and wondering if I could run out of TCP sockets, or file descriptors, or something else I may have missed? Aiming for high availability, so I am trying to be proactive and find limits before clients find limits. Currently around 4 000 listeners hasn't posed any problems. Thanks for any input you may have. Sincerely, Tom __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/
Re: problem with usb on amd64 SMP
On Sun, Apr 20, 2008 at 8:37 PM, Benoit Chesneau <[EMAIL PROTECTED]> wrote: > Hi all, > > When I use GENERIC.SMP on my machine (AMD Athlon(tm) 64 X2 Dual Core > Processor 4400+, asus M2N-MX) i have problem with smp, all usb ports > except teh one with the mouse are disabled , so is the hub on my apple > cinema display. At boot I get this message : > > usb1 at ohci0: USB revision 1.0 > uhub1 at usb1 "NVIDIA OHCI root hub" rev 1.00/1.00 addr 1 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > ehci_sync_hc: tsleep() = 35 > uhub0: device problem, disabling port 2 > uhidev0 at uhub1 port 1 configuration 1 interface 0 "Razer Razer > Diamondback Optical Mouse" rev 2.00/1.00 addr 2 > uhidev0: iclass 3/1 > ums0 at uhidev0: 7 buttons and Z dir. > > It works well when I use GENERIC It might be an hardware problem since > I tested it with an ubuntu livecd and everything was ok (with smp). > However this problem appear after I changed my graphic card from a > nvidia 7100GS to a radeonhd RX2400 Pro. > > Any idee what could be the problem ? I suspect a problem with apic or > an irq conflict.. Dmesg is attached. > > - benont > OpenBSD 4.3-current (GENERIC.MP) #1631: Tue Apr 15 15:40:39 MDT 2008 > [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 2146824192 (2047MB) > avail mem = 2073030656 (1976MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf06f0 (60 entries) > bios0: vendor American Megatrends Inc. version "0907" date 09/27/2007 > bios0: ASUSTeK Computer INC. M2N-MX > acpi0 at bios0: rev 2 > acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT > acpi0: wakeup devices PS2K(S0) PS2M(S0) UAR1(S0) USB0(S0) USB2(S0) P0P1(S0) > HDAC(S0) P0P2(S0) BR11(S0) NMAC(S0) NSMB(S0) PWRB(S0) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2310.98 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: apic clock running at 200MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2310.65 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW > cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative > ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins > acpihpet0 at acpi0: 2500 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (P0P1) > acpiprt2 at acpi0: bus 2 (P0P2) > acpiprt3 at acpi0: bus 3 (BR11) > acpiprt4 at acpi0: bus 4 (BR12) > acpicpu0 at acpi0: PSS > acpicpu1 at acpi0: PSS > acpibtn0 at acpi0: PWRB > cpu0: PowerNow! K8 2310 MHz: speeds: 2300 2200 2000 1800 1000 MHz > pci0 at mainbus0 bus 0: configuration mode 1 > "NVIDIA MCP61 Memory" rev 0xa1 at pci0 dev 0 function 0 not configured > pcib0 at pci0 dev 1 function 0 "NVIDIA MCP61 ISA" rev 0xa2 > nviic0 at pci0 dev 1 function 1 "NVIDIA MCP61 SMBus" rev 0xa2 > iic0 at nviic0 > spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5 > spdmem1 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-5300CL5 > iic1 at nviic0 > "NVIDIA MCP61 Memory" rev 0xa2 at pci0 dev 1 function 2 not configured > ohci0 at pci0 dev 2 function 0 "NVIDIA MCP61 USB" rev 0xa2: apic 2 int 11 > (irq 11), version 1.0, legacy support > ehci0 at pci0 dev 2 function 1 "NVIDIA MPC61 USB" rev 0xa2: apic 2 int 10 > (irq 10) > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1 > ppb0 at pci0 dev 4 function 0 "NVIDIA MCP61" rev 0xa1 > pci1 at ppb0 bus 1 > emu0 at pci1 dev 7 function 0 "Creative Labs SoundBlaster Live" rev 0x0a: > apic 2 int 11 (irq 11) > ac97: codec id 0x83847658 (SigmaTel STAC9758/59) > ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D > audio0 at emu0 > "Creative Labs PCI Gameport Joystick" rev 0x0a at pci1 dev 7 function 1 not > configured > azalia0 at pci0 dev 5 function 0 "NVIDIA MCP61 HD Audio" rev 0xa2: apic 2 > int 11 (irq 11) > azalia0: codec[s]: Analog Devices/0x19
Re: Really large drives (was Re: Is there a "badblocks"-equivalent for OpenBSD?)
David Gwynne wrote: solaris suffers from this problem. you cant use big disks with 32bit solaris kernels. For UFS, at least, but doesn't ZFS on i386 (not amd64) scale? -- Matthew Weigel hacker unique & idempot.ent
Re: Is there a "badblocks"-equivalent for OpenBSD?
* Siegbert Marschall <[EMAIL PROTECTED]> [2008-04-21 02:38:10]: > Hello, > > > > > I'm curious how much more failure in the new "perpendicular" drives > > you are seeing. I can certainly see various drive makers pushing > > capacity irrespective of reliability. Germane to this case, some > > of them reduce the reserve storage for bad sectors for that extra > > storage. Tisk tisk. > > > to new, not that many in use yet and it will likely take a while for > the errors to show up. when searching for an unrelated issue with the > samsung 1TB, I found some reports of high numbers of reassigned > sectors in SMART data, floating around. but that is not necessarily > an issue, could be just an aspect of the higher density handled with > more ECC. nice poster one has to admit, the "terabite". :) > > the bad-sectors we saw where mostly found in cheap 80/160GB single > platter drives. of the 300/400/500 we had only a few errors so far. > > i think there are some companies out there having collected a lot > more smart-data the we do, wonder what they do with it... ;) > > -sm > Well, I would not consider SMART to be the most accurate way of doing things. Implementations will vary from company to company, and even within their product lines. Also, you can make more money if you set the SMART thresholds higher than they ought to be so users think their drive is performing better/won't be replaced under warranty. This sounds paranoid, but some companies are just obsessed with making more money rather than a quality product. -- Travers Buda
Re: Is there a "badblocks"-equivalent for OpenBSD?
Hello, > > I'm curious how much more failure in the new "perpendicular" drives > you are seeing. I can certainly see various drive makers pushing > capacity irrespective of reliability. Germane to this case, some > of them reduce the reserve storage for bad sectors for that extra > storage. Tisk tisk. > to new, not that many in use yet and it will likely take a while for the errors to show up. when searching for an unrelated issue with the samsung 1TB, I found some reports of high numbers of reassigned sectors in SMART data, floating around. but that is not necessarily an issue, could be just an aspect of the higher density handled with more ECC. nice poster one has to admit, the "terabite". :) the bad-sectors we saw where mostly found in cheap 80/160GB single platter drives. of the 300/400/500 we had only a few errors so far. i think there are some companies out there having collected a lot more smart-data the we do, wonder what they do with it... ;) -sm
Re: timeouts on http connects outbound
19 April 2008 c. 20:31:44 Moe Sizlak wrote: > To followup on this question I have updated my sysctl settings, > changed pf.conf and added the scrub out line recommended. > > Also my dist is 4.3 openbsd flashdist. (not 4.2) > > > Result of all changes proposed: No change. > > Pages like http://marc.info etc still time out. Had the same problem with ADSL provider, only those values helped in pf.conf: scrub in on pppoe0 max-mss 1400 fragment reassemble scrub out on pppoe0 max-mss 1400 no-df random-id fragment reassemble BTW, if you want to set up WWW cache (squid), be ready for more problems... -- Best wishes, Vadim Zhukov
Re: X60 Tablet Wacom, Atheros 5213 & others
15 April 2008 c. 19:36:41 joshua stein wrote: > > - Pen doesn't work at all. Windows say it's connected to the LPC > > chip mentioned above. Does this mean that I have to write a driver > > for it (and modify wscons framework to support touch strength, and > > then modify Xorg wscons driver, BTW removing usbtablet(4))? Looks > > like nice effort for me, but'll take a lot of time... > > if it's like my x61 tablet, it's a serial wacom tablet and it's just > on a non-standard irq and address so you have to tell the kernel > where to probe for pccom0. > > 'config -e' your kernel, 'change pccom0', set the irq to 5 and port > to 0x200. > > and it should attach pccom0. you'll need the "linux" wacom driver > for xorg compiled without usb stuff: > > http://linuxwacom.sourceforge.net/ > > > - Buttons near display (are actual in the tablet mode) do not work > > either. Windows says they're connected in parallel to pen device. > > they were working fine for me on my x61. they generate keycodes you > can see by running xev. i made them send normal keys with xmodmap: > > ! little button that can only be pressed with the tip of the pen > !keycode 198 = > ! screen rotation key > !keycode 204 = > ! whatever that button is to the right of rotate > !keycode 199 = > > keycode 203 = Escape > > ! d-pad arrows and center > keycode 209 = Up > keycode 206 = Left > keycode 205 = Right > keycode 207 = Down > keycode 200 = Return > > i eventually setup something to respond to keycode 204 and call a > script that ran 'xrandr' to rotate the display. > > > - FireWire and finger scanner are not supported and do not work > > either. BTW, does anyone have any docs for the last one (see dmesg > > for more info)? > > finger scanner is working, it's your ugen0 device. fprint works > just fine with it: > > http://reactivated.net/fprint/wiki/Main_Page > > i have more info on the x61 tablet at http://lowerca.se/laptops/ Thank you, thanks, thanks, thanks! I'll try to rewrite existing tablet input driver, but do not now when I'll have enough time for that. Key are visible in xev(1), so whis is not a problem now... And cool info on your site is there, too. Thank you again for your answer, now it's time to hack :) -- Best wishes, Vadim Zhukov
Re: pf and hosts.deny
On Sat, Apr 19, 2008 at 10:02 AM, Vikas N Kumar < [EMAIL PROTECTED]> wrote: > Any help will be appreciated. > Thanks for all the help provided. Regards Vikas
Re: Really large drives (was Re: Is there a "badblocks"-equivalent for OpenBSD?)
On 21/04/2008, at 4:46 AM, Matthew Weigel wrote: Chris Zakelj wrote: a non-issue on 64-bit platforms Whether a system is 64-bit or not isn't very relevant to this - that mostly establishes what the memory address space is, *not* the size of integers that can be used by the system. solaris suffers from this problem. you cant use big disks with 32bit solaris kernels.
Re: Really large drives (was Re: Is there a "badblocks"-equivalent for OpenBSD?)
Matthew Weigel wrote: Chris Zakelj wrote: ... I'm wondering if thought is being given on how to make the physical size (not filesystem... I totally understand why those should be kept small) limitation of http://www.openbsd.org/faq/faq14.html#LargeDrive http://www.openbsd.org/43.html "New Functionality: ... o The ffs layer is now 64-bit disk block address clean. This means that disks, partitions and filesystems larger than 2TB are now supported, with the exception of statfs(2) and quotas." So, yes, thought is being given... Sweet... I missed that when I did my quick reading of the new features. Is it safe to assume the guideline of 1M RAM per 1G of file system to do a reasonable fsck is still valid? a non-issue on 64-bit platforms Whether a system is 64-bit or not isn't very relevant to this - that mostly establishes what the memory address space is, *not* the size of integers that can be used by the system. Ok... insufficient understanding on my part there :)
Re: Environment variables
On Fri, Apr 18, 2008 at 09:28:24PM -0400, Ted Unangst wrote:
> On Apr 18, 2008, at 1:47 PM, Paul Irofti <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Apr 18, 2008 at 03:20:56PM +0200, Jurjen Oskam wrote:
>>>
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> int main(int argc, char **argv)
>>> {
>>> char *var1 = "FOO=TESTING";
>>
>> A bit OT but you should really alloc that or use a static.
>
> Why?
Mainly because its bad practice and expanding the code would probably
lead to at least a couple of bugs related to string manipulation.
Re: Really large drives (was Re: Is there a "badblocks"-equivalent for OpenBSD?)
Chris Zakelj wrote: Travers Buda wrote: I can certainly see various drive makers pushing capacity irrespective of reliability. Germane to this case, some of them reduce the reserve storage for bad sectors for that extra storage. Going along with this, on a recent trip to my local computer megastore, I noticed that 1TB SATA drives are starting to hit the market. With RAID cards like arc(4) around, that makes it pretty easy to build really massive arrays. I'm no good at reading code, so I'm wondering if thought is being given on how to make the physical size (not filesystem... I totally understand why those should be kept small) limitation of http://www.openbsd.org/faq/faq14.html#LargeDrive a non-issue on 64-bit platforms (realizing, of course, that it's a lot harder than something like making an int into a double, since fdisk and so on would need to be made 64bit safe as well)? Yeah! Got a 500Gig eSATA mounted, 6 slices. The problem is not how to address the drive, the problem is to backup all that data. That is, eventually, 4 gig per DVD, or XFS, or a cluster. My main database I can't live without is 500Meg expected to grow 1 Gig by end-of-year. (one on 500). Would take an average of 3 months to be reconstructed. So, I still can burn DVDs for a while. When this will not be possible anymore, I'll go to clusters. Going to clusters, I just need good hardware. I don't envision an insanity as a terabytes large raids. What would be a budget to recover a multi-terabytes array? Don't answer, this is my pension plan.
Re: Really large drives (was Re: Is there a "badblocks"-equivalent for OpenBSD?)
Chris Zakelj wrote: ... I'm wondering if thought is being given on how to make the physical size (not filesystem... I totally understand why those should be kept small) limitation of http://www.openbsd.org/faq/faq14.html#LargeDrive http://www.openbsd.org/43.html "New Functionality: ... o The ffs layer is now 64-bit disk block address clean. This means that disks, partitions and filesystems larger than 2TB are now supported, with the exception of statfs(2) and quotas." So, yes, thought is being given... a non-issue on 64-bit platforms Whether a system is 64-bit or not isn't very relevant to this - that mostly establishes what the memory address space is, *not* the size of integers that can be used by the system. -- Matthew Weigel hacker unique & idempot.ent
problem with usb on amd64 SMP
Hi all, When I use GENERIC.SMP on my machine (AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, asus M2N-MX) i have problem with smp, all usb ports except teh one with the mouse are disabled , so is the hub on my apple cinema display. At boot I get this message : usb1 at ohci0: USB revision 1.0 uhub1 at usb1 "NVIDIA OHCI root hub" rev 1.00/1.00 addr 1 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 ehci_sync_hc: tsleep() = 35 uhub0: device problem, disabling port 2 uhidev0 at uhub1 port 1 configuration 1 interface 0 "Razer Razer Diamondback Optical Mouse" rev 2.00/1.00 addr 2 uhidev0: iclass 3/1 ums0 at uhidev0: 7 buttons and Z dir. It works well when I use GENERIC It might be an hardware problem since I tested it with an ubuntu livecd and everything was ok (with smp). However this problem appear after I changed my graphic card from a nvidia 7100GS to a radeonhd RX2400 Pro. Any idee what could be the problem ? I suspect a problem with apic or an irq conflict.. Dmesg is attached. - benont OpenBSD 4.3-current (GENERIC.MP) #1631: Tue Apr 15 15:40:39 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2146824192 (2047MB) avail mem = 2073030656 (1976MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf06f0 (60 entries) bios0: vendor American Megatrends Inc. version "0907" date 09/27/2007 bios0: ASUSTeK Computer INC. M2N-MX acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT acpi0: wakeup devices PS2K(S0) PS2M(S0) UAR1(S0) USB0(S0) USB2(S0) P0P1(S0) HDAC(S0) P0P2(S0) BR11(S0) NMAC(S0) NSMB(S0) PWRB(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2310.98 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2310.65 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 2500 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 2 (P0P2) acpiprt3 at acpi0: bus 3 (BR11) acpiprt4 at acpi0: bus 4 (BR12) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: PWRB cpu0: PowerNow! K8 2310 MHz: speeds: 2300 2200 2000 1800 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 "NVIDIA MCP61 Memory" rev 0xa1 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 "NVIDIA MCP61 ISA" rev 0xa2 nviic0 at pci0 dev 1 function 1 "NVIDIA MCP61 SMBus" rev 0xa2 iic0 at nviic0 spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5 spdmem1 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-5300CL5 iic1 at nviic0 "NVIDIA MCP61 Memory" rev 0xa2 at pci0 dev 1 function 2 not configured ohci0 at pci0 dev 2 function 0 "NVIDIA MCP61 USB" rev 0xa2: apic 2 int 11 (irq 11), version 1.0, legacy support ehci0 at pci0 dev 2 function 1 "NVIDIA MPC61 USB" rev 0xa2: apic 2 int 10 (irq 10) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1 ppb0 at pci0 dev 4 function 0 "NVIDIA MCP61" rev 0xa1 pci1 at ppb0 bus 1 emu0 at pci1 dev 7 function 0 "Creative Labs SoundBlaster Live" rev 0x0a: apic 2 int 11 (irq 11) ac97: codec id 0x83847658 (SigmaTel STAC9758/59) ac97: codec features headphone, 20 bit DAC, 20 bit ADC, SigmaTel 3D audio0 at emu0 "Creative Labs PCI Gameport Joystick" rev 0x0a at pci1 dev 7 function 1 not configured azalia0 at pci0 dev 5 function 0 "NVIDIA MCP61 HD Audio" rev 0xa2: apic 2 int 11 (irq 11) azalia0: codec[s]: Analog Devices/0x1986 audio1 at azalia0 pciide0 at pci0 dev 6 function 0 "NVIDIA MCP61 IDE" rev 0xa2: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 190782MB, 390721968 sectors atapiscsi0 at pciide0 channel 0 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI0
Really large drives (was Re: Is there a "badblocks"-equivalent for OpenBSD?)
Travers Buda wrote: I can certainly see various drive makers pushing capacity irrespective of reliability. Germane to this case, some of them reduce the reserve storage for bad sectors for that extra storage. Going along with this, on a recent trip to my local computer megastore, I noticed that 1TB SATA drives are starting to hit the market. With RAID cards like arc(4) around, that makes it pretty easy to build really massive arrays. I'm no good at reading code, so I'm wondering if thought is being given on how to make the physical size (not filesystem... I totally understand why those should be kept small) limitation of http://www.openbsd.org/faq/faq14.html#LargeDrive a non-issue on 64-bit platforms (realizing, of course, that it's a lot harder than something like making an int into a double, since fdisk and so on would need to be made 64bit safe as well)?
Re: Is there a "badblocks"-equivalent for OpenBSD?
* Siegbert Marschall <[EMAIL PROTECTED]> [2008-04-20 11:19:31]: > Hello, > > > I don't know if anyone brought this up, and I hate to state the > > obvious, but if you're getting bad blocks then the hard drive has > > exhausted its ability to deal with them on its own and should be > > replaced. Otherwise you'll see data loss/corruption and a higher > > probability of a total drive failure. > > not always, bad sectors get only reasigned if either the sector > containing data can still be read after a few tries eg. the drive > notices when reading that this part is going bad or when you write > to the sector. in case you stumble upon a bad sector and just try > to read it, nothing will happen. write it and it will get reasigned. > > with the current drive-capacities and data densities bad sectors are > kind of "unavoidable" in consumer grade drives. that's why it is > recommended to read scan your raid of cheap drives often, so the > drives have a chance to discover sectors going bad when they are > still readable. > > currently we just take drives with some bad sectors out of the raid, > write check them, see if they are gone, mark them and use them again. > if it happens again after that they go out for warranty. of course > not for really important data, there it's SAS or fresh drives. ;) > > -sm > > I'm curious how much more failure in the new "perpendicular" drives you are seeing. I can certainly see various drive makers pushing capacity irrespective of reliability. Germane to this case, some of them reduce the reserve storage for bad sectors for that extra storage. Tisk tisk. -- Travers Buda
Re: Is there a "badblocks"-equivalent for OpenBSD?
Hello, > I don't know if anyone brought this up, and I hate to state the > obvious, but if you're getting bad blocks then the hard drive has > exhausted its ability to deal with them on its own and should be > replaced. Otherwise you'll see data loss/corruption and a higher > probability of a total drive failure. not always, bad sectors get only reasigned if either the sector containing data can still be read after a few tries eg. the drive notices when reading that this part is going bad or when you write to the sector. in case you stumble upon a bad sector and just try to read it, nothing will happen. write it and it will get reasigned. with the current drive-capacities and data densities bad sectors are kind of "unavoidable" in consumer grade drives. that's why it is recommended to read scan your raid of cheap drives often, so the drives have a chance to discover sectors going bad when they are still readable. currently we just take drives with some bad sectors out of the raid, write check them, see if they are gone, mark them and use them again. if it happens again after that they go out for warranty. of course not for really important data, there it's SAS or fresh drives. ;) -sm
