* PROBLEM: Kernel 2.6.10 crashing repeatedly and hard
@ 2004-12-30 0:31 Georg C. F. Greve
2004-12-30 16:23 ` Georg C. F. Greve
0 siblings, 1 reply; 88+ messages in thread
From: Georg C. F. Greve @ 2004-12-30 0:31 UTC (permalink / raw)
To: linux-kernel; +Cc: dm-crypt
[-- Attachment #1.1: Type: text/plain, Size: 496 bytes --]
Hi all,
I've been moving things on my server to use software RAID5 of the LVM,
trying out to use the device mapper (dm-crypt) on top of that with an
ext3 filesystem and have seen repeated hard crashes. The machine was
entirely dead.
Since the machine was quite stable for a couple of days with 2.6.10
before moving to the software RAID setup, my suspicion is that it is
related to either LVM, DM, EXT3 or any combination of the three.
This is what I could preserve in output from the crashes:
[-- Attachment #1.2: crash1 --]
[-- Type: text/plain, Size: 1069 bytes --]
Call Trace:
[<c0141131>] cache_flusharray+0x41/0xb0
[<c0141398>] kmem_cache_free+0x38/0x40
[<c0158c4f>] free_buffer_head+0x1f/0x70
[<c0158a19>] try_to_free_buffers+0x59/0x90
[<c019e65d>] journal_try_to_free_buffers+0xbd/0x130
[<c018fe20>] ext3_releasepage+0x30/0x60
[<c0156d99>] try_to_release_page+0x39/0x50
[<c014349f>] shrink_list+0x35f/0x440
[<c0143707>] shrink_cache+0x187/0x430
[<c017cf97>] mb_cache_shrink_fn+0x167/0x170
[<c0142e62>] shrink_slab+0x82/0x1b0
[<c0143ff2>] shrink_zone+0xb2/0xe0
[<c014447e>] balance_pgdat+0x24e/0x2d0
[<c01445dc>] kswapd+0xdc/0x100
[<c0130c30>] autoremove_wake_function+0x0/0x40
[<c0102dc2>] ret_from_fork+0x6/0x14
[<c0130c30>] autoremove_wake_function+0x0/0x40
[<c0144500>] kswapd+0x0/0x100
[<c010129d>] kernel_thread_helper+0x5/0x18
Code: 7e 8d 46 38 89 04 24 8b 44 24 1c 8b 15 10 c0 53 c0 8b 0c b8 8d 81 00 00 00
40 c1 e8 0c c1 e0 05 8b 5c 02 1c 8b 53 04 8b ß3 89 02 <89> 50 04 8b 43 0c c7 03
00 01 10 00 29 c1 c7 43 04 00 02 20 00
<6>note: kswapd0[196] exited with preempt_count 1
[-- Attachment #1.3: crash2 --]
[-- Type: text/plain, Size: 1140 bytes --]
[<c01565fe>] alloc_page_buffers+0x1e/0x90
[<c0156ea8>] create_empty_buffers+0x18/0x90
[<c0157613>] __block_prepare_write+0x373/0x3c0
[<c0157d70>] block_prepare_write+0x20/0x30
[<c018f0f0>] ext3_get_block+0x0/0x70
[<c018f5b8>] ext3_prepare_write+0x58/0x110
[<c018f0f0>] ext3_get_block+0x0/0x70
[<c013a59f>] generic_file_buffered_write+0x19f/0x600
[<c0130c30>] autoremove_wake_function+0x0/0x40
[<c013ac53>] __generic_file_aio_write_nolock+0x37/0x90
[<c013b0f0>] generic_file_aio_write_nolock+0x37/0x90
[<c013b0f0>] generic_file_aio_write+0x60/0xc0
[<c018d18a>] ext3_file_write+0x2a/0xa0
[<c01547db>] do_sync_write+0xab/0xe0
[<c01383b4>] wait_on_page_writeback_range+0x74/0x120
[<c0130c30>] autoremove_wake_function+0x0/0x40
[<c018d2b7>] ext3_sync_file+0xb7/0xc0
[<c015489c>] vfs_write+0x8c/0xd0
[<c015498d>] sys_write+0x3d/0x70
[<c0102eef>] syscall_call+0x7/0xb
Code: 14 42 25 ff ff 00 00 89 51 10 8b 3c 24 66 8b 04 47 66 89 41 14 8b 44 24 24
3b 50 58 73 06 4e 83 fe ff 75 b5 8b 51 04 8b 01 89 02 <89> 50 04 c7 01 00 01 10
00 c7 41 04 00 02 20 00 66 83 79 14 ff
<6>note: mythbackend[16084] exited with preempt_count 1
[-- Attachment #1.4: crash3 --]
[-- Type: text/plain, Size: 1165 bytes --]
EFLAGS: 00010002 (2.6.10)
EIP is at free_block+0x45/0xd0
eax: 46484849 ebx: df2b1000 ecx: df2b1050 edx: df2ab000
esi: c183cd80 edi: 00000001 ebp: 00000018 esp: c188fef8
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 6, threadinfo:c188e000 task=c185ca20)
Stack: c183cdb8 c1858810 c1858800 00000018 c183cd80 c0141724 c183cd80 c1858810
00000018 c183ccb8 c183cd80 00000002 c183cce0 c01417c6 c183cd80 c1858800
00000000 c183ccb8 c183ce10 00000003 c170fc20 c183b000 c170fc24 00000000
Call Trace:
[<c0141724>] drain_array_locked+0x54&0x80
[<c01417c6>] cache_reap+0x75/0x1e0
[<c012cb07>] worker_thread+0x197/0x230
[<c0141750>] cache_reap+0x0/0x1e0
[<c011a590>] default_wake_function+0x0/0x20
[<c011a590>] default_wake_function+0x0/0x20
[<c012c970>] worker_thread+0x0/0x230
[<c0130827>] kthread+0xa7/0xb0
[<c0130790>] kthread+0x0/0xb0
[<c010129d>] kernel_thread_helper+0x5/0x18
Code: 7e 8d 46 38 89 04 24 8b 44 24 1c 8b 15 10 c0 53 c0 8b 0c b8 8d 81 00 00 00
40 c1 e8 0c c1 e0 05 8b 5c 02 1c 8b 53 04 8b 03 89 02 <89> 50 04 8b 43 0c c7 03
00 01 10 00 29 c1 c7 43 04 00 02 20 00
<6>note: events/0[6] exited with preempt_count 1
[-- Attachment #1.5: Type: text/plain, Size: 394 bytes --]
All of them have in common the notice of some process having
"exited with preempt_count 1"
and all of them happened within three hours -- this is the first time
that a mainline kernel has been behaving so consistently unstable for
me, in fact.
The machine is a P4 Xeon 2.8GHz running Debian GNU/Linux (sarge) and
here are the lspci and lsusb -vvv output and the Kernel configuration
file:
[-- Attachment #1.6: lspci.vvv --]
[-- Type: text/plain, Size: 13457 bytes --]
0000:00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub (rev 02)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80f6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at f4000000 (32-bit, prefetchable) [size=64M]
Capabilities: [e4] #09 [2106]
Capabilities: [a0] AGP version 3.0
Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP+ GART64- 64bit- FW- Rate=x8
0000:00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fc900000-fe9fffff
Prefetchable memory behind bridge: dfe00000-efdfffff
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at eec0 [size=32]
0000:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at ef00 [size=32]
0000:00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at ef20 [size=32]
0000:00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at ef40 [size=32]
0000:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 23
Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #0a [20a0]
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fea00000-feafffff
Prefetchable memory behind bridge: efe00000-efefffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at <unassigned>
Region 1: I/O ports at <unassigned>
Region 2: I/O ports at <unassigned>
Region 3: I/O ports at <unassigned>
Region 4: I/O ports at fc00 [size=16]
Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]
0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) SATA Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at efe0 [size=8]
Region 1: I/O ports at efac [size=4]
Region 2: I/O ports at efa0 [size=8]
Region 3: I/O ports at efa8 [size=4]
Region 4: I/O ports at ef90 [size=16]
0000:00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 10
Region 4: I/O ports at 0400 [size=32]
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at e800 [size=256]
Region 1: I/O ports at ee80 [size=64]
Region 2: Memory at febff800 (32-bit, non-prefetchable) [size=512]
Region 3: Memory at febff400 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) (prog-if 00 [VGA])
Subsystem: ASUSTeK Computer Inc.: Unknown device 80cf
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at fe9e0000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 3.0
Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=32 ArqSz=2 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8
0000:02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 808a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (8000ns max), Cache Line Size: 0x04 (16 bytes)
Interrupt: pin A routed to IRQ 20
Region 0: Memory at feaff800 (32-bit, non-prefetchable) [size=2K]
Region 1: I/O ports at dc00 [size=128]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (5750ns min, 7750ns max), Cache Line Size: 0x04 (16 bytes)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at feaf8000 (32-bit, non-prefetchable) [size=16K]
Region 1: I/O ports at d800 [size=256]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
0000:02:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (4000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at efefe000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at efeff000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at feaff400 (32-bit, non-prefetchable) [size=512]
0000:02:0b.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min, 2000ns max), Cache Line Size: 0x04 (16 bytes)
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at d400 [disabled] [size=256]
Region 1: Memory at feafe000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at feae0000 [disabled] [size=64K]
0000:02:0c.0 Unknown mass storage controller: Promise Technology, Inc. PDC20518 SATAII 150 IDE Controller (rev 02)
Subsystem: Promise Technology, Inc. PDC20518 SATAII 150 IDE Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 0x01 (4 bytes)
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at d080 [size=128]
Region 2: I/O ports at de00 [size=256]
Region 3: Memory at feafd000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at feac0000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at feab0000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at dd00 [size=256]
Region 1: Memory at feaff000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[-- Attachment #1.7: lsusb.vvv --]
[-- Type: text/plain, Size: 12785 bytes --]
Bus 005 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 8
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.10-lirc ehci_hcd
iProduct 2 Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
iSerial 1 0000:00:1d.7
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 8
wHubCharacteristic 0x0008
Ganged power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x01
PortPwrCtrlMask 0x00 0x00
Bus 004 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.10-lirc uhci_hcd
iProduct 2 Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
iSerial 1 0000:00:1d.3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0x01
Bus 003 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.10-lirc uhci_hcd
iProduct 2 Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
iSerial 1 0000:00:1d.2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0x01
Bus 002 Device 003: ID 04e6:5115 SCM Microsystems, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x04e6 SCM Microsystems, Inc.
idProduct 0x5115
bcdDevice 4.16
iManufacturer 1 SCM Microsystems Inc.
iProduct 2 SCR33x USB Smart Card Reader
iSerial 5 504057B8
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 93
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 3 CCID Class
bmAttributes 0xa0
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 11 Chip/SmartCard
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 4 CCID Interface
ChipCard Interface Descriptor:
bLength 54
bDescriptorType 33
bcdCCID 1.00
nMaxSlotIndex 0
bVoltageSupport 1 5.0V
dwProtocols 3 T=0 T=1
dwDefaultClock 4000
dwMaxiumumClock 12000
bNumClockSupported 0
dwDataRate 9600 bps
dwMaxDataRate 115200 bps
bNumDataRatesSupp. 0
dwMaxIFSD 252
dwSyncProtocols 00000000
dwMechanical 00000000
dwFeatures 000100BA
Auto configuration based on ATR
Auto voltage selection
Auto clock change
Auto baud rate change
Auto PPS made by CCID
TPDU level exchange
dwMaxCCIDMsgLen 263
bClassGetResponse echo
bClassEnvelope echo
wlcdLayout none
bPINSupport 0
bMaxCCIDBusySlots 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 16
Bus 002 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.10-lirc uhci_hcd
iProduct 2 Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
iSerial 1 0000:00:1d.1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0x01
Bus 001 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.10-lirc uhci_hcd
iProduct 2 Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0x01
[-- Attachment #1.8: config-2.6.10 --]
[-- Type: text/plain, Size: 40065 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10-lirc
# Wed Dec 29 17:33:55 2004
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=m
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PC-card bridges
#
CONFIG_PCMCIA_PROBE=y
#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_HOTPLUG_PCI_ACPI=m
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
CONFIG_HOTPLUG_PCI_SHPC=m
# CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=y
#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
#
# Parallel IDE protocol modules
#
# CONFIG_PARIDE_ATEN is not set
# CONFIG_PARIDE_BPCK is not set
# CONFIG_PARIDE_BPCK6 is not set
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
# CONFIG_PARIDE_FIT2 is not set
# CONFIG_PARIDE_FIT3 is not set
# CONFIG_PARIDE_EPAT is not set
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
# CONFIG_PARIDE_KTTI is not set
# CONFIG_PARIDE_ON20 is not set
# CONFIG_PARIDE_ON26 is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_AHCI is not set
# CONFIG_SCSI_SATA_SVW is not set
CONFIG_SCSI_ATA_PIIX=y
# CONFIG_SCSI_SATA_NV is not set
CONFIG_SCSI_SATA_PROMISE=y
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
CONFIG_SCSI_DEBUG=m
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=m
CONFIG_MD_RAID5=y
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m
#
# I2O device support
#
CONFIG_I2O=m
# CONFIG_I2O_CONFIG is not set
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
#
# Networking support
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
CONFIG_IP_TCPDIAG=y
CONFIG_IP_TCPDIAG_IPV6=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_TUNNEL=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CT_PROTO_SCTP=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
CONFIG_IP_NF_MATCH_SCTP=m
CONFIG_IP_NF_MATCH_COMMENT=m
CONFIG_IP_NF_MATCH_CONNMARK=m
CONFIG_IP_NF_MATCH_HASHLIMIT=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_TARGET_CONNMARK=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
# CONFIG_IP6_NF_RAW is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
# CONFIG_R8169_NAPI is not set
CONFIG_SK98LIN=y
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=m
#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_SLIP=m
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_FC is not set
CONFIG_SHAPER=m
CONFIG_NETCONSOLE=m
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_TSDEV=m
CONFIG_INPUT_TSDEV_SCREEN_X=240
CONFIG_INPUT_TSDEV_SCREEN_Y=320
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_VORTEX=m
CONFIG_GAMEPORT_FM801=m
CONFIG_GAMEPORT_CS461x=m
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PARKBD=m
CONFIG_SERIO_PCIPS2=m
# CONFIG_SERIO_RAW is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_UINPUT=m
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=m
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
#
# Linux InfraRed Controller
#
CONFIG_LIRC_SUPPORT=m
CONFIG_LIRC_MAX_DEV=2
# CONFIG_LIRC_I2C is not set
# CONFIG_LIRC_GPIO is not set
# CONFIG_LIRC_BT829 is not set
# CONFIG_LIRC_IT87 is not set
# CONFIG_LIRC_ATIUSB is not set
# CONFIG_LIRC_MCEUSB is not set
CONFIG_LIRC_SERIAL=m
CONFIG_LIRC_HOMEBREW=y
# CONFIG_LIRC_SERIAL_ANIMAX is not set
# CONFIG_LIRC_SERIAL_IRDEO is not set
# CONFIG_LIRC_SERIAL_IRDEO_REMOTE is not set
# CONFIG_LIRC_SERIAL_TRANSMITTER is not set
# CONFIG_LIRC_SERIAL_IGOR is not set
CONFIG_LIRC_SERIAL_COM1=y
# CONFIG_LIRC_SERIAL_COM2 is not set
# CONFIG_LIRC_SERIAL_COM3 is not set
# CONFIG_LIRC_SERIAL_COM4 is not set
# CONFIG_LIRC_SERIAL_OTHER is not set
CONFIG_LIRC_PORT_SERIAL=0x3f8
CONFIG_LIRC_IRQ_SERIAL=0x4
# CONFIG_LIRC_SIR is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# IPMI
#
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=y
# CONFIG_IPMI_SI is not set
CONFIG_IPMI_WATCHDOG=m
# CONFIG_IPMI_POWEROFF is not set
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_MACHZ_WDT is not set
#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set
#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_INTEL_MCH is not set
CONFIG_AGP_NVIDIA=m
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=m
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_STUB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m
#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m
#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
#
# Video For Linux
#
#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_OVCAMCHIP=m
#
# Radio Adapters
#
CONFIG_RADIO_CADET=m
CONFIG_RADIO_RTRACK=m
CONFIG_RADIO_RTRACK2=m
CONFIG_RADIO_AZTECH=m
CONFIG_RADIO_GEMTEK=m
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_RADIO_SF16FMI=m
# CONFIG_RADIO_SF16FMR2 is not set
CONFIG_RADIO_TERRATEC=m
CONFIG_RADIO_TRUST=m
CONFIG_RADIO_TYPHOON=m
# CONFIG_RADIO_TYPHOON_PROC_FS is not set
CONFIG_RADIO_ZOLTRIX=m
#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=y
#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m
#
# Supported USB Adapters
#
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_DIBUSB=m
CONFIG_DVB_DIBUSB_MISDESIGNED_DEVICES=y
CONFIG_DVB_DIBCOM_DEBUG=y
CONFIG_DVB_CINERGYT2=m
CONFIG_DVB_CINERGYT2_TUNING=y
CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32
CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512
CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250
# CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE is not set
#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_SKYSTAR=m
CONFIG_DVB_B2C2_USB=m
#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m
#
# Supported DVB Frontends
#
#
# Customise DVB Frontends
#
#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA80XX=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1X93=m
#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
#
# DVB-C (cable) frontends
#
CONFIG_DVB_ATMEL_AT76C651=m
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_STV0297=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
#
# ISA devices
#
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set
#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
#
# USB support
#
CONFIG_USB=y
CONFIG_USB_DEBUG=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m
CONFIG_USB_BLUETOOTH_TTY=m
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_RW_DETECT=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_MTOUCH=m
CONFIG_USB_EGALAX=m
CONFIG_USB_XPAD=m
CONFIG_USB_ATI_REMOTE=m
#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m
#
# USB Multimedia devices
#
CONFIG_USB_DABUSB=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_W9968CF=m
#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
#
# USB Host-to-Host Cables
#
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_GENESYS=y
CONFIG_USB_NET1080=y
CONFIG_USB_PL2301=y
CONFIG_USB_KC2190=y
#
# Intelligent USB Devices/Gadgets
#
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_ZAURUS=y
CONFIG_USB_CDCETHER=y
#
# USB Network Adapters
#
CONFIG_USB_AX8817X=y
#
# USB port drivers
#
CONFIG_USB_USS720=m
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
# CONFIG_USB_SERIAL_IPW is not set
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y
#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_TIGL=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
CONFIG_USB_CYTHERM=m
CONFIG_USB_PHIDGETKIT=m
CONFIG_USB_PHIDGETSERVO=m
CONFIG_USB_TEST=m
#
# USB ATM/DSL drivers
#
#
# USB Gadget Support
#
CONFIG_USB_GADGET=m
# CONFIG_USB_GADGET_DEBUG_FILES is not set
CONFIG_USB_GADGET_NET2280=y
CONFIG_USB_NET2280=m
# CONFIG_USB_GADGET_PXA2XX is not set
# CONFIG_USB_GADGET_GOKU is not set
# CONFIG_USB_GADGET_SA1100 is not set
# CONFIG_USB_GADGET_LH7A40X is not set
# CONFIG_USB_GADGET_DUMMY_HCD is not set
# CONFIG_USB_GADGET_OMAP is not set
CONFIG_USB_GADGET_DUALSPEED=y
# CONFIG_USB_ZERO is not set
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_GADGETFS=m
# CONFIG_USB_FILE_STORAGE is not set
# CONFIG_USB_G_SERIAL is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
CONFIG_REISERFS_CHECK=y
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_REISERFS_FS_XATTR is not set
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_DEBUG=y
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_RT=y
CONFIG_XFS_QUOTA=y
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
CONFIG_NTFS_DEBUG=y
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
CONFIG_ADFS_FS=m
CONFIG_ADFS_FS_RW=y
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
# CONFIG_HFSPLUS_FS is not set
CONFIG_BEFS_FS=m
CONFIG_BEFS_DEBUG=y
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_QNX4FS_FS=m
CONFIG_QNX4FS_RW=y
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
CONFIG_UFS_FS_WRITE=y
#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_TEST=m
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y
[-- Attachment #1.9: Type: text/plain, Size: 49 bytes --]
And for completeness, here are the lsmod output
[-- Attachment #1.10: lsmod --]
[-- Type: text/plain, Size: 2175 bytes --]
Module Size Used by
w83627hf 26016 0
lm75 6932 0
eeprom 6680 0
i2c_sensor 3968 3 w83627hf,lm75,eeprom
i2c_isa 2816 0
8139cp 17152 0
eth1394 18696 0
dvb_ttpci 78864 3
saa7146_vv 43520 1 dvb_ttpci
saa7146 15656 2 dvb_ttpci,saa7146_vv
ves1820 6148 1 dvb_ttpci
stv0299 9860 1 dvb_ttpci
tda8083 6020 1 dvb_ttpci
stv0297 7936 1 dvb_ttpci
sp8870 7436 1 dvb_ttpci
ves1x93 6788 1 dvb_ttpci
ttpci_eeprom 3328 1 dvb_ttpci
ohci1394 30724 0
ieee1394 300344 2 eth1394,ohci1394
snd_intel8x0 27808 1
snd_ac97_codec 66528 1 snd_intel8x0
snd_pcm_oss 47268 0
snd_mixer_oss 17024 2 snd_pcm_oss
snd_pcm 80004 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer 21380 1 snd_pcm
snd 46052 6 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
snd_page_alloc 8324 2 snd_intel8x0,snd_pcm
i2c_i801 8460 0
ehci_hcd 41604 0
uhci_hcd 30348 0
shpchp 90372 0
pci_hotplug 11524 1 shpchp
8250_pnp 9088 0
8250 20708 1 8250_pnp
serial_core 18816 1 8250
pcspkr 4300 0
tsdev 6592 0
tuner 20772 0
tvaudio 20256 0
msp3400 24104 0
bttv 142288 0
video_buf 17540 2 saa7146_vv,bttv
firmware_class 8448 3 dvb_ttpci,sp8870,bttv
i2c_algo_bit 9608 1 bttv
btcx_risc 4872 1 bttv
i2c_core 18816 19 w83627hf,lm75,eeprom,i2c_sensor,i2c_isa,dvb_ttpci,ves1820,stv0299,tda8083,stv0297,sp8870,ves1x93,ttpci_eeprom,i2c_i801,tuner,tvaudio,msp3400,bttv,i2c_algo_bit
lirc_serial 12800 1
lirc_dev 12040 2 lirc_serial
8139too 22784 0
[-- Attachment #1.11: Type: text/plain, Size: 38 bytes --]
and the output of cat /proc/scsi/scsi
[-- Attachment #1.12: proc-scsi --]
[-- Type: text/plain, Size: 1282 bytes --]
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: TOSHIBA Model: CD-ROM XM-3801TA Rev: 3386
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: IBM Model: DCAS-34330 Rev: S60B
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: HP Model: C5110A Rev: 3701
Type: Processor ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: _NEC Model: DVD_RW ND-1300A Rev: 1.05
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Maxtor 6Y120M0 Rev: YAR5
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Maxtor 6Y120M0 Rev: YAR5
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi5 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi7 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
[-- Attachment #1.13: Type: text/plain, Size: 387 bytes --]
All help very much appreciated.
If you need more info, please let me know.
Regards,
Georg
--
Georg C. F. Greve <greve@fsfeurope.org>
Free Software Foundation Europe (http://fsfeurope.org)
GNU Business Network (http://mailman.gnubiz.org)
Brave GNU World (http://brave-gnu-world.org)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 88+ messages in thread* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 0:31 PROBLEM: Kernel 2.6.10 crashing repeatedly and hard Georg C. F. Greve @ 2004-12-30 16:23 ` Georg C. F. Greve 2004-12-30 17:39 ` Peter T. Breuer 0 siblings, 1 reply; 88+ messages in thread From: Georg C. F. Greve @ 2004-12-30 16:23 UTC (permalink / raw) To: linux-kernel; +Cc: dm-crypt [-- Attachment #1: Type: text/plain, Size: 940 bytes --] [ update ] Okay, tried to find out what is causing the kernel to crash and so I replaced the dm-crypt part by cryptoloop: same effect. Then I tried ext3 on top of LVM2 RAID5 with no encryption and it still crashes. Not sure what is causing the problem exactly, but it does not seem that dm-crypt is to blame anymore. The message I saw on the remote console when it crashed with pure ext3 on raid5 was: Assertion failure in journal_start() at fs/jbd/transaction.c:271: "handle->h_transaction->t_journal == journal" Hope this helps -- filed the bug as #3968 on buzilla.kernel.org, more info at http://bugzilla.kernel.org/show_bug.cgi?id=3968 Help appreciated, let me know if you have an idea. Regards, Georg -- Georg C. F. Greve <greve@gnu.org> Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World (http://brave-gnu-world.org) [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 16:23 ` Georg C. F. Greve @ 2004-12-30 17:39 ` Peter T. Breuer 2004-12-30 17:53 ` Sandro Dentella ` (2 more replies) 0 siblings, 3 replies; 88+ messages in thread From: Peter T. Breuer @ 2004-12-30 17:39 UTC (permalink / raw) To: linux-raid; +Cc: linux-kernel, dm-crypt In gmane.linux.raid Georg C. F. Greve <greve@fsfeurope.org> wrote: > The message I saw on the remote console when it crashed with pure ext3 > on raid5 was: > > Assertion failure in journal_start() at fs/jbd/transaction.c:271: "handle->h_transaction->t_journal == journal" > Yes, well, don't put the journal on the raid partition. Put it elsewhere (anyway, journalling and raid do not mix, as write ordering is not - deliberately - preserved in raid, as far as I can tell). Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 17:39 ` Peter T. Breuer @ 2004-12-30 17:53 ` Sandro Dentella 2004-12-30 18:31 ` Peter T. Breuer 2004-12-30 19:50 ` Michael Tokarev 2005-01-07 6:21 ` Clemens Schwaighofer 2 siblings, 1 reply; 88+ messages in thread From: Sandro Dentella @ 2004-12-30 17:53 UTC (permalink / raw) To: linux-raid, linux-kernel > Yes, well, don't put the journal on the raid partition. Put it > elsewhere (anyway, journalling and raid do not mix, as write ordering > is not - deliberately - preserved in raid, as far as I can tell). ???, do you mean it? which filesystem would you use for a 2TB RAID5 array? I always used reiserfs for raid1/raid5 arrays... sandro *:-) -- Sandro Dentella *:-) e-mail: sandro@e-den.it http://www.tksql.org TkSQL Home page - My GPL work ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 17:53 ` Sandro Dentella @ 2004-12-30 18:31 ` Peter T. Breuer 0 siblings, 0 replies; 88+ messages in thread From: Peter T. Breuer @ 2004-12-30 18:31 UTC (permalink / raw) To: linux-raid; +Cc: linux-kernel In gmane.linux.raid Sandro Dentella <sandro@e-den.it> wrote: > > Yes, well, don't put the journal on the raid partition. Put it > > elsewhere (anyway, journalling and raid do not mix, as write ordering > > is not - deliberately - preserved in raid, as far as I can tell). > > ???, do you mean it? which filesystem would you use for a 2TB RAID5 array? I Whatever one you are using now. Just turn off journalling, or at least move the journal somewhere else (and safe!). Or perhaps use metadata-only journalling (but reiser does that by default, does it not?). That should keep you happy. > always used reiserfs for raid1/raid5 arrays... Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 17:39 ` Peter T. Breuer 2004-12-30 17:53 ` Sandro Dentella @ 2004-12-30 19:50 ` Michael Tokarev 2004-12-30 21:39 ` Peter T. Breuer [not found] ` <41D45C1F.5030307-XAri/EZa3C4vJsYlp49lxw@public.gmane.org> 2005-01-07 6:21 ` Clemens Schwaighofer 2 siblings, 2 replies; 88+ messages in thread From: Michael Tokarev @ 2004-12-30 19:50 UTC (permalink / raw) To: Peter T. Breuer; +Cc: linux-raid, linux-kernel, dm-crypt Peter T. Breuer wrote: > In gmane.linux.raid Georg C. F. Greve <greve@fsfeurope.org> wrote: > > Yes, well, don't put the journal on the raid partition. Put it > elsewhere (anyway, journalling and raid do not mix, as write ordering > is not - deliberately - preserved in raid, as far as I can tell). This is a sort of a nonsense, really. Both claims, it seems. I can't say for sure whenever write ordering is preserved by raid -- it should, and if it isn't, it's a bug and should be fixed. Nothing else is wrong with placing journal into raid (the same as the filesystem in question). Suggesting to remove journal just isn't fair: the journal is here for a reason. And, finally, the kernel should not crash. If something like this is unsupported, it should refuse to do so, instead of crashing randomly. /mjt ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 19:50 ` Michael Tokarev @ 2004-12-30 21:39 ` Peter T. Breuer 2005-01-02 19:42 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith [not found] ` <41D45C1F.5030307-XAri/EZa3C4vJsYlp49lxw@public.gmane.org> 1 sibling, 1 reply; 88+ messages in thread From: Peter T. Breuer @ 2004-12-30 21:39 UTC (permalink / raw) To: linux-raid; +Cc: linux-kernel, dm-crypt In gmane.linux.raid Michael Tokarev <mjt@tls.msk.ru> wrote: > Peter T. Breuer wrote: > > In gmane.linux.raid Georg C. F. Greve <greve@fsfeurope.org> wrote: > > > > Yes, well, don't put the journal on the raid partition. Put it > > elsewhere (anyway, journalling and raid do not mix, as write ordering > > is not - deliberately - preserved in raid, as far as I can tell). > > This is a sort of a nonsense, really. Both claims, it seems. It's perfectly correct, as far as I know! > I can't say for sure whenever write ordering is preserved by > raid -- There is nothing that attempts expliciitly to maintain the ordering in RAID (talking about mirroring here). Mirror requests are submitted _asynchronously_ to the block subsystem for each device in the mirror, for each incoming request. The kernel doesn't even have any way of tracking in what order requests are emitted (it would need a counter field in each request and there is not one), let alone in what order they are emitted per device, under the device it is aiming at. And then of course there is no way at all of telling the underlying devices in what order to treat the requests either - and what about request aggregation? Requests are normally aggregated by the kernel before being sent to devices - ok, I think I recall that RAID turns that off on itself by using its own make_request function, but it doesn't control request aggregation in the sub-devices. And I don't know what happens if you throw the extra resync thread into the mix, but there certainly IS a RAID kernel thread that does nothing else than retry failed requests (and do resyncs?) - which of course will be out of order if ever they are successfully completed by the thread. If we move on to RAID5, then the situation is simply even more complicated because we no longer have to think about when solid, physical, mirrored data is written, but when "virtual" redundant data is written (and read). I'm not even sure what in the kernel in general can possibly guarantee that the sequence write-read-read-write-read can remain ordered that way when an unplug event interrupts the sequence. > it should, and if it isn't, it's a bug and should be > fixed. Nothing else is wrong with placing journal into raid It's been that way forever. > (the same as the filesystem in question). What's wrong is that the journal will be mirrored (if it's a mirror). That means that (1) its data will be written twice, which is a big deal since ALL the i/o goes through the journal first, and (2) the journal is likely to be inconsistent (since it is so active) if you get one of those creeping invisible RAID corruptions that can crop up inevitably in RAID normal use. > Suggesting to remove > journal just isn't fair: the journal is here for a reason. Well, I'd remove it: presumably his aim is to reduce fsck times after a crash. But consider - if he has had a crash, it is likely that his data is corrupted, so he WANTS to check. All that a journal does is guarantee consistency of a FS, not correctness. Personally, I prefer to see the incorrectness. If you don't want to check the filesystem you can always just choose to not run fsck! And in this case the journal is a significant extra risk factor, because it is ON the falied medium, and on the part that is most active, moreover! All you have to do to make things safer is take the journal OFF the raid array. You immediately remove the potential for corruption IN the journal (I believe that's what he has seen anyway - damage to the disk under the journal), which is where we have deduced by the above argument that the major source of likely corruptions must lie. There's also no good sense in data-journalling, but I don't think reiserfs does that anyway (it didn't use to, I know - ext3 was the first to do data journalling, although even that's a misnomer, since you try writing a 4GB file as an atomic operation ...). Journals do no magic. You have to consider if they introduce more benefits than dangers. > And, finally, the kernel should not crash. Well, I'm afraid that like everyone else it is dependent on hardware and authors, both of which are fallible! > If something like > this is unsupported, it should refuse to do so, instead of > crashing randomly. ??? Morality is so comforting :-). Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2004-12-30 21:39 ` Peter T. Breuer @ 2005-01-02 19:42 ` Andy Smith 2005-01-02 20:18 ` Peter T. Breuer 2005-01-05 9:56 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith 0 siblings, 2 replies; 88+ messages in thread From: Andy Smith @ 2005-01-02 19:42 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 843 bytes --] On Thu, Dec 30, 2004 at 10:39:42PM +0100, Peter T. Breuer wrote: > In gmane.linux.raid Michael Tokarev <mjt@tls.msk.ru> wrote: > > Peter T. Breuer wrote: > > > In gmane.linux.raid Georg C. F. Greve <greve@fsfeurope.org> wrote: > > > > > > Yes, well, don't put the journal on the raid partition. Put it > > > elsewhere (anyway, journalling and raid do not mix, as write ordering > > > is not - deliberately - preserved in raid, as far as I can tell). > > > > This is a sort of a nonsense, really. Both claims, it seems. > > It's perfectly correct, as far as I know! Not really wishing to get into the middle of a flame war, but I didn't really see how this could be true so I asked for more info on ext3-users. I got the following response: https://listman.redhat.com/archives/ext3-users/2005-January/msg00003.html [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-02 19:42 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith @ 2005-01-02 20:18 ` Peter T. Breuer 2005-01-03 0:30 ` Andy Smith 2005-01-05 9:56 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith 1 sibling, 1 reply; 88+ messages in thread From: Peter T. Breuer @ 2005-01-02 20:18 UTC (permalink / raw) To: linux-raid Andy Smith <andy@strugglers.net> wrote: > [-- text/plain, encoding quoted-printable, charset: us-ascii, 22 lines --] > > On Thu, Dec 30, 2004 at 10:39:42PM +0100, Peter T. Breuer wrote: > > In gmane.linux.raid Michael Tokarev <mjt@tls.msk.ru> wrote: > > > Peter T. Breuer wrote: > > > > In gmane.linux.raid Georg C. F. Greve <greve@fsfeurope.org> wrote: > > > > > > > > Yes, well, don't put the journal on the raid partition. Put it > > > > elsewhere (anyway, journalling and raid do not mix, as write ordering > > > > is not - deliberately - preserved in raid, as far as I can tell). > > > > > > This is a sort of a nonsense, really. Both claims, it seems. > > > > It's perfectly correct, as far as I know! > > Not really wishing to get into the middle of a flame war, but I > didn't really see how this could be true so I asked for more info on > ext3-users. > > I got the following response: > > https://listman.redhat.com/archives/ext3-users/2005-January/msg00003.html Interesting - I'll post it (there is no flame war): > * From: "Stephen C. Tweedie" <sct redhat com> > * To: Andy Smith <andy lug org uk> > * Cc: Stephen Tweedie <sct redhat com>, ext3 users list <ext3-users > * redhat com> > * Subject: Re: ext3 journal on software raid > * Date: Sat, 01 Jan 2005 22:19:23 +0000 (snip) > Disks and IO subsystems in general don't preserve IO ordering. This is true. > ext3 is > designed not to care. That is surprising - write-order preservation is precisely the condition that reiserfs requires for correct journal behaviour, and Hans Reiser tld be so himself (sometime, some reiserfs mailing list, at the time, etc). It would be surprising if Stephen managed to do without it, but his condition is definitely weaker. He merely requires to be _told_ (synchronously) when each i/o has ended, in the order that it ends, I think is what he says below. I'm not sure that raid can guarrantee precisely that either. There might be minor disorderings on a SMP system with preemption, if for example, one request is handled on one cpu and another on another, and the acks are handled crosswise. There might be a small temporal displacement. I haven't thought about it. What I can say is that it makes no _attempt_ to respect that condition. Whether it does or not I cannot exactly say. > As long as the raid device tells the truth about > when the data is actually committed to disk (all of the mirror volumes > are uptodate) for a given IO, ext3 should be quite happy. Uuff .. as I said, it is not quite clear to me that this (very weak) condition is absolutely respected. Umm ... no, endio for the whole request is sent back AFTER the mirror i/os have completed, but exactly WHEN after is indeterminate on a preemptive (SMP) system. The mirrors might have been factually updated for two requests in temporal order A B, but might report endio in order B A. However, I think that he probably is calling A then B in a single thread, which means that B won't even be generated until A is acked. OK - I think Stephen is probably saying that the ack must be sent back AFTER the status of the writes on the mirror disks is known. Yes, that is guarranteed (unless you apply an async raid patch ...). > > What's wrong is that the journal will be mirrored (if it's a mirror). > > That means that (1) its data will be written twice, which is a big deal > > since ALL the i/o goes through the journal first > > Not true; by default, only metadata goes through the journal, not data. He is saying that data is not journalled by default on ext3. I don't see that as a comment about raid, and inasmuch as it means anything it means that his comment "not true" is about as close to a rather strange (political?) untruth as you can get in CS, since all the journal's data WILL be written twice - it's up to you how much that is. Whether you pass the data through the journal or not, all the data you choose to pass will be written twice, be it zero, some, or all. > > > and (2) the journal > > is likely to be inconsistent (since it is so active) if you get one of > > those creeping invisible RAID corruptions that can crop up inevitably > > in RAID normal use. > > Umm, if soft raid is expected to have silent invisible corruptions in > normal use, It is, just as is all types of RAID. This is a very strange thing for Stephen to say - I cannot believe that he is as naive as he makes himself out to be about RAID here and I don't know why he should say that (presuming that he really knows better). > then you shouldn't be using it, period. That's got zero to > do with journaling. It implies that one should not be doing journalling on top of it. (The logic for why RAID corrupts silently is that errors accumulate at n times the normal rate per sector, but none of them are detected by RAID (no crc), and when a disk drops out then you get a good chance of picking up a corrupted copy instead of a good copy, because nobody has checked the copy meanwhiles to see if it matches the original). Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-02 20:18 ` Peter T. Breuer @ 2005-01-03 0:30 ` Andy Smith 2005-01-03 6:41 ` Neil Brown 2005-01-03 8:03 ` Peter T. Breuer 0 siblings, 2 replies; 88+ messages in thread From: Andy Smith @ 2005-01-03 0:30 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 2117 bytes --] On Sun, Jan 02, 2005 at 09:18:13PM +0100, Peter T. Breuer wrote: > Stephen Tweedie wrote: > > Umm, if soft raid is expected to have silent invisible corruptions in > > normal use, > > It is, just as is all types of RAID. This is a very strange thing for > Stephen to say - I cannot believe that he is as naive as he makes > himself out to be about RAID here and I don't know why he should say > that (presuming that he really knows better). > > > then you shouldn't be using it, period. That's got zero to > > do with journaling. > > It implies that one should not be doing journalling on top of it. > > (The logic for why RAID corrupts silently is that errors accumulate at > n times the normal rate per sector, but none of them are detected by > RAID (no crc), and when a disk drops out then you get a good chance of > picking up a corrupted copy instead of a good copy, because nobody > has checked the copy meanwhiles to see if it matches the original). I have no idea which of you to believe now. :( I currently only have one system using software raid, and several of my employer's machines using hardware raid, all of which have various raid-1, -5 and -10 setups and all use only ext3. Let's focus on the personal machine of mine for now since it uses Linux software RAID and therefore on-topic here. It has /boot on a small RAID-1, and the rest of the system is on RAID-5 with an additional RAID-0 just for temporary things. There is nowhere that is not software RAID to put the journals, so would you be recommending that I turn off journalling and basically use it as ext2? What I do know is that none of what you say is in the software raid howto, and if you are right, it really should be. Neither is it in any ext3 documentation and there is no warning on any distribution installer I have ever used (those that understand RAID and LVM and are happy to set that up at install time with ext3). Also everyone that I have spoken to about this knows nothing about it, so what you are saying, if correct, would seem to have far-reaching implications. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 0:30 ` Andy Smith @ 2005-01-03 6:41 ` Neil Brown 2005-01-03 8:37 ` Peter T. Breuer 2005-01-03 8:03 ` Peter T. Breuer 1 sibling, 1 reply; 88+ messages in thread From: Neil Brown @ 2005-01-03 6:41 UTC (permalink / raw) To: Andy Smith; +Cc: linux-raid On Monday January 3, andy@strugglers.net wrote: > > I have no idea which of you to believe now. :( Well, how about I wade in..... (almost*) No block storage device will guarantee that write ordering is maintained. Neither will read requests necessarily be ordered. Any SCSI, IDE, or similar disc drive in Linux (or any other non-toy OS) will have requests managed by an "elevator algorithm" which coalesces adjacent blocks and tries to re-order requests to make optimal use of the device. A RAID controller, whether software, firmware, or hardware, will also re-order requests to make best use of the devices. Any filesystem that assumes that requests will not be re-ordered is broken, as the assumption is wrong. I would be *very* surprised if Reiserfs makes this assumption. Until relatively recently, the only assumption that could be made is that a write request will be handled sometime between when it is made, and when the request completes (i.e. the end_io callback is called). If several requests are concurrent they could commit in any order. With only this guarantee, the simplest approach for a journalling filesystem is to write the content of a journal entry, wait for the writes to complete, and then write a single block "header" which describes and hence commits that journal entry. The journal entry is not "safe" until this second write completes. This is equally applicable for IDE drives, SCSI drives, software RAID1, software RAID5, hardware RAID etc. More recently (2.6 only) Linux has had support for "write barriers". The idea here is that you submit a number of write requests, then a "barrier", then some more write requests. (The "barrier" might be a flag on the last request of a list, I'm not sure of that detail). The meaning is that no write request submitted after the barrier will be attempted until all requests submitted before the barrier are complete. Some drives support this concept natively so Linux simply does not re-order requests across a barrier, and sends the barrier at the appropriate time. Drives can do their own re-ordering but will not reorder across a barrier (if they support the barrier concept). If Linux needs to write a barrier to a device that doesn't support barriers (as the md/raid currently doesn't) it will (should) submit all requests before the barrier, flush them out, wait for them to complete, then allow other requests to be forwarded. In short, md/raid provides the same guarantees as normal drives, and any filesystem that expects more is broken. Definitely put your journal on RAID with at least as much redundancy as your main filesystem (I put my filesystem on raid5 and my journal on raid1). NeilBrown * I happen to know that the "umem" NVRAM driver will never re-order requests, as there is no value in re-ordering requests to RAM. But it is the exception, not the rule. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 6:41 ` Neil Brown @ 2005-01-03 8:37 ` Peter T. Breuer 0 siblings, 0 replies; 88+ messages in thread From: Peter T. Breuer @ 2005-01-03 8:37 UTC (permalink / raw) To: linux-raid Neil Brown <neilb@cse.unsw.edu.au> wrote: > Well, how about I wade in..... Sure! :-) > A RAID controller, whether software, firmware, or hardware, will also > re-order requests to make best use of the devices. Possibly. I have written block device drivers that maintain write order, however (or at least do so if you ask them to, with the right switch), because ... > Any filesystem that assumes that requests will not be re-ordered is > broken, as the assumption is wrong. > I would be *very* surprised if Reiserfs makes this assumption. .. because that is EXACTLY what Hans Reiser has said to me. I don't think I've kept the mail, but I remember it. a quick google for reiserfs + write ordering shows up some suggestive quotes: > We cannot use the buffer.c dirty list anyway because bdflush can write > those buffers to disk at any time. Transactions have to control the > write ordering ... (hey, that was Hans quoting Stephen). From the Linux High Availability website (http://linuxha.trick.ca/DataRedundancyByDrbd): Since later WRITE requests might depend on successful finished previous ones, this is needed to assure strict write ordering on both nodes. ... Well, I'm not going to search now. Onecan simply ask HR and find out what the current status is vis a vis reiserfs. To be certain what I am talking about, I'll define write ordering as: Writes are not reordered and reads may not be reordered beyond the writes that bound them either side. > Until relatively recently, the only assumption that could be made is > that a write request will be handled sometime between when it is made, > and when the request completes (i.e. the end_io callback is called). This _appears_ to be what Stephen is saying he needs, from which I deduce that he probably has a single-threaded implementation in ext3, because: > If several requests are concurrent they could commit in any order. Yes. > With only this guarantee, the simplest approach for a journalling > filesystem is to write the content of a journal entry, wait for the > writes to complete, and then write a single block "header" which > describes and hence commits that journal entry. The journal entry is > not "safe" until this second write completes. > > This is equally applicable for IDE drives, SCSI drives, software > RAID1, software RAID5, hardware RAID etc. I would agree. No matter what the hardware people say, or what claims are made for equipment, I don't see how there can be any way of knowing the order in which writes are committed internally. I only hope that reads are not reordered beyond writes :-). (this would cause you to read the wrong data: you go W1 R1 W2 and yet read in R1 what you wrote in W2!) > More recently (2.6 only) Linux has had support for "write barriers". > The idea here is that you submit a number of write requests, then a Well, I seem to recall that at some point "request specials" were to act as request barriers, but I don't know if that is still the case. When a driver received one it had to flush all outstanding requests before acking the special. Perhaps Linus gave up on people implementing that and put the support in the kernel core, so as to enforce it? It would be possible. Or maybe he dropped it. > "barrier", then some more write requests. (The "barrier" might be a > flag on the last request of a list, I'm not sure of that detail). The > meaning is that no write request submitted after the barrier will be > attempted until all requests submitted before the barrier are > complete. Some drives support this concept natively so Linux simply > does not re-order requests across a barrier, and sends the barrier at > the appropriate time. Drives can do their own re-ordering but will > not reorder across a barrier (if they support the barrier concept). Yes. > If Linux needs to write a barrier to a device that doesn't support > barriers (as the md/raid currently doesn't) it will (should) submit > all requests before the barrier, flush them out, wait for them to > complete, then allow other requests to be forwarded. But I at least don't know if "Linux" does that :-). By "Linux" you either mean some part of the block subsystem, or fs's acting on their own. > In short, md/raid provides the same guarantees as normal drives, and > any filesystem that expects more is broken. Normal drives do not reorder writes. Their drivers also probably make no attempt to do so, nor not to do so, but in the nature of things (single input, single output) it is unlikely that they do. Software RAID on the other hand is fundamentally parallel so the intrinsic liklihood that something somewhere gets reordered is much higher, and I believe you agree with me that no attempt is made to either check on or prevent it. > Definitely put your journal on RAID with at least as much redundancy > as your main filesystem (I put my filesystem on raid5 and my journal > on raid1). :-) But I don't think you ought to put the journal on raid - what good does it do you to do so? (apart from testing out raid :). After all, the journal integrity is not itself guaranteed by a journal, and it is a point of failure for the whole system, and it is a point where you have doubled i/o density over and above the normal journal rate, which is already extremely high if you do data journalling, since ALL the data on the system flows through that point first. So you will stress the disk there as well as making all your data vulnerable to anything that happens there. What extra benefit do you get from putting it there that is not balanced by greater risks? I'm curious! Surely raid is about "spreading your eggs out through several baskets"? Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 0:30 ` Andy Smith 2005-01-03 6:41 ` Neil Brown @ 2005-01-03 8:03 ` Peter T. Breuer 2005-01-03 8:58 ` Guy ` (2 more replies) 1 sibling, 3 replies; 88+ messages in thread From: Peter T. Breuer @ 2005-01-03 8:03 UTC (permalink / raw) To: linux-raid Andy Smith <andy@strugglers.net> wrote: > [-- text/plain, encoding quoted-printable, charset: us-ascii, 45 lines --] > > On Sun, Jan 02, 2005 at 09:18:13PM +0100, Peter T. Breuer wrote: > > Stephen Tweedie wrote: > > > Umm, if soft raid is expected to have silent invisible corruptions in > > > normal use, > > > > It is, just as is all types of RAID. This is a very strange thing for > > Stephen to say - I cannot believe that he is as naive as he makes > > himself out to be about RAID here and I don't know why he should say > > that (presuming that he really knows better). > > > > > then you shouldn't be using it, period. That's got zero to > > > do with journaling. > > > > It implies that one should not be doing journalling on top of it. > > > > (The logic for why RAID corrupts silently is that errors accumulate at > > n times the normal rate per sector, but none of them are detected by > > RAID (no crc), and when a disk drops out then you get a good chance of > > picking up a corrupted copy instead of a good copy, because nobody > > has checked the copy meanwhiles to see if it matches the original). > > I have no idea which of you to believe now. :( Both of us. We have not disagreed fundamentally. Read closely! Stephen says "IF (my caps) soft raid is expected to have ...". Well, it is, just like any RAID. Similarly he didn't disagree that journal data is written twice, if you read closely, he merely pointed out that the DEFAULT (my caps) setting in ext3 is not to write data (as opposed to metadata) into the journal at all. So he avoided issues of substance there (and/but gave a strange spin to them). What he did claim that is factually interesting and new is that ext3 works if acks from the media are merely received after the fact. That's a far weaker requirement than for reiserfs, for example. It seems to me to imply that the implementation is single-threaded and highly synchronous. > I currently only have one system using software raid, and several of > my employer's machines using hardware raid, all of which have > various raid-1, -5 and -10 setups and all use only ext3. All fine - as I said, the only thing I'd do is make sure that the journal is not kept on the raid partition(s), and possibly turn off data journalling in favour of metadata journalling only. > Let's focus on the personal machine of mine for now since it uses > Linux software RAID and therefore on-topic here. It has /boot on a > small RAID-1, This is always a VERY bad idea. /boot and /root want to be on as simple and uncomplicated a system as possible. Moreover, they never change, so what is the point of having a real time mirror for them? It would be sufficient to copy them every day (which is what I do) at file system level to another partition, if you want a spare copy for emergencies. > and the rest of the system is on RAID-5 with an > additional RAID-0 just for temporary things. That's fine. > There is nowhere that is not software RAID to put the journals, so Well, you can make somewhere. You only require an 8MB (one cylinder) partition. > would you be recommending that I turn off journalling and basically > use it as ext2? No, I'd be recommending that you make an 8MB partition for a journal. This is also handy in case you "wear through" the disk under the journal because of the high i/o there. Well, it's happened to me on two disks, but doubtless people will cntest that! IF it happens, all you have to do is use a cylinder somewhere else. > What I do know is that none of what you say is in the software raid > howto, But nothing said is other than obvious, and is a matter of probabilities and risk management, so I don't see why it should be in a howto! That's your business, not the howto's. > and if you are right, it really should be. Neither is it in I don't think it should be. It should be somewhere in ext3 docs (there was a time when ext3 wouldn't work on raid1 at all, butthat got fixed somehow), but then documenting how your FS works on some particular media is not really part of the documentation scope for the FS! > any ext3 documentation and there is no warning on any distribution > installer I have ever used (those that understand RAID and LVM and > are happy to set that up at install time with ext3). Also everyone > that I have spoken to about this knows nothing about it, so what you Everyone knows about it, because none of us is saying anything that is not obvious. Yes, data is written through the journal twice. EVERYTHING is written through the journal twice if the journal is on RAID1, because everything on RAID1 is written twice. That is obvious, no? And then you get i/o storms through the journal in any case on journalled raid, whenever you do data journalling. It is just doubled if you do that on a raid system. And there is a risk of silent corruption on all raid systems - that is well known. DIfferent raid systems do different thigs to compensate, such as periodically recalculating the parity on everything. But when you have redundant data and a corruption occurs, which of the two datasets do you believe? You have to choose one of them! You guess wrong half the time, if you guess ("you" is a raid system). Hence "silent corruption". > are saying, if correct, would seem to have far-reaching > implications. I don't think so! Why? RAID protects you against certain sorts of risk. It also exposes you to other sorts of risk. Where is the far-reaching implication in that? It is for you to balance the risks and benefits. Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 8:03 ` Peter T. Breuer @ 2005-01-03 8:58 ` Guy 2005-01-03 10:18 ` Partiy error detection - was " Brad Campbell 2005-01-03 12:11 ` Michael Tokarev 2 siblings, 0 replies; 88+ messages in thread From: Guy @ 2005-01-03 8:58 UTC (permalink / raw) To: 'Peter T. Breuer', linux-raid "Well, you can make somewhere. You only require an 8MB (one cylinder) partition." So, it is ok for your system to fail when this disk fails? I don't want system failures when a disk fails, so mirror (or RAID5) everything required to keep your system running. "And there is a risk of silent corruption on all raid systems - that is well known." I question this.... I bet a non-mirror disk has similar risk as a RAID1. But with a RAID1, you know when a difference occurs, if you want. Guy -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Peter T. Breuer Sent: Monday, January 03, 2005 3:03 AM To: linux-raid@vger.kernel.org Subject: Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith <andy@strugglers.net> wrote: > [-- text/plain, encoding quoted-printable, charset: us-ascii, 45 lines --] > > On Sun, Jan 02, 2005 at 09:18:13PM +0100, Peter T. Breuer wrote: > > Stephen Tweedie wrote: > > > Umm, if soft raid is expected to have silent invisible corruptions in > > > normal use, > > > > It is, just as is all types of RAID. This is a very strange thing for > > Stephen to say - I cannot believe that he is as naive as he makes > > himself out to be about RAID here and I don't know why he should say > > that (presuming that he really knows better). > > > > > then you shouldn't be using it, period. That's got zero to > > > do with journaling. > > > > It implies that one should not be doing journalling on top of it. > > > > (The logic for why RAID corrupts silently is that errors accumulate at > > n times the normal rate per sector, but none of them are detected by > > RAID (no crc), and when a disk drops out then you get a good chance of > > picking up a corrupted copy instead of a good copy, because nobody > > has checked the copy meanwhiles to see if it matches the original). > > I have no idea which of you to believe now. :( Both of us. We have not disagreed fundamentally. Read closely! Stephen says "IF (my caps) soft raid is expected to have ...". Well, it is, just like any RAID. Similarly he didn't disagree that journal data is written twice, if you read closely, he merely pointed out that the DEFAULT (my caps) setting in ext3 is not to write data (as opposed to metadata) into the journal at all. So he avoided issues of substance there (and/but gave a strange spin to them). What he did claim that is factually interesting and new is that ext3 works if acks from the media are merely received after the fact. That's a far weaker requirement than for reiserfs, for example. It seems to me to imply that the implementation is single-threaded and highly synchronous. > I currently only have one system using software raid, and several of > my employer's machines using hardware raid, all of which have > various raid-1, -5 and -10 setups and all use only ext3. All fine - as I said, the only thing I'd do is make sure that the journal is not kept on the raid partition(s), and possibly turn off data journalling in favour of metadata journalling only. > Let's focus on the personal machine of mine for now since it uses > Linux software RAID and therefore on-topic here. It has /boot on a > small RAID-1, This is always a VERY bad idea. /boot and /root want to be on as simple and uncomplicated a system as possible. Moreover, they never change, so what is the point of having a real time mirror for them? It would be sufficient to copy them every day (which is what I do) at file system level to another partition, if you want a spare copy for emergencies. > and the rest of the system is on RAID-5 with an > additional RAID-0 just for temporary things. That's fine. > There is nowhere that is not software RAID to put the journals, so Well, you can make somewhere. You only require an 8MB (one cylinder) partition. > would you be recommending that I turn off journalling and basically > use it as ext2? No, I'd be recommending that you make an 8MB partition for a journal. This is also handy in case you "wear through" the disk under the journal because of the high i/o there. Well, it's happened to me on two disks, but doubtless people will cntest that! IF it happens, all you have to do is use a cylinder somewhere else. > What I do know is that none of what you say is in the software raid > howto, But nothing said is other than obvious, and is a matter of probabilities and risk management, so I don't see why it should be in a howto! That's your business, not the howto's. > and if you are right, it really should be. Neither is it in I don't think it should be. It should be somewhere in ext3 docs (there was a time when ext3 wouldn't work on raid1 at all, butthat got fixed somehow), but then documenting how your FS works on some particular media is not really part of the documentation scope for the FS! > any ext3 documentation and there is no warning on any distribution > installer I have ever used (those that understand RAID and LVM and > are happy to set that up at install time with ext3). Also everyone > that I have spoken to about this knows nothing about it, so what you Everyone knows about it, because none of us is saying anything that is not obvious. Yes, data is written through the journal twice. EVERYTHING is written through the journal twice if the journal is on RAID1, because everything on RAID1 is written twice. That is obvious, no? And then you get i/o storms through the journal in any case on journalled raid, whenever you do data journalling. It is just doubled if you do that on a raid system. And there is a risk of silent corruption on all raid systems - that is well known. DIfferent raid systems do different thigs to compensate, such as periodically recalculating the parity on everything. But when you have redundant data and a corruption occurs, which of the two datasets do you believe? You have to choose one of them! You guess wrong half the time, if you guess ("you" is a raid system). Hence "silent corruption". > are saying, if correct, would seem to have far-reaching > implications. I don't think so! Why? RAID protects you against certain sorts of risk. It also exposes you to other sorts of risk. Where is the far-reaching implication in that? It is for you to balance the risks and benefits. Peter - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 88+ messages in thread
* Partiy error detection - was Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 8:03 ` Peter T. Breuer 2005-01-03 8:58 ` Guy @ 2005-01-03 10:18 ` Brad Campbell 2005-01-03 12:11 ` Michael Tokarev 2 siblings, 0 replies; 88+ messages in thread From: Brad Campbell @ 2005-01-03 10:18 UTC (permalink / raw) To: Peter T. Breuer; +Cc: linux-raid Peter T. Breuer wrote: > And there is a risk of silent corruption on all raid systems - that is > well known. DIfferent raid systems do different thigs to compensate, > such as periodically recalculating the parity on everything. But when > you have redundant data and a corruption occurs, which of the two > datasets do you believe? You have to choose one of them! You guess > wrong half the time, if you guess ("you" is a raid system). Hence > "silent corruption". Just on this point. With RAID-6 I guess you can get a majority rules type of ruling on which data block is the dud. Unless you come up with 3 different results in which case something is really not right in lego land. I wonder perhaps about a userspace app that you can run to check all the parity blocks. On RAID-5 it should be able to tell you, you have a naff stripe, but on RAID-6 in theory if it's only a single drive that is a problem you should be able to correct the block. Regards, Brad ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 8:03 ` Peter T. Breuer 2005-01-03 8:58 ` Guy 2005-01-03 10:18 ` Partiy error detection - was " Brad Campbell @ 2005-01-03 12:11 ` Michael Tokarev 2005-01-03 14:23 ` Peter T. Breuer 2 siblings, 1 reply; 88+ messages in thread From: Michael Tokarev @ 2005-01-03 12:11 UTC (permalink / raw) To: linux-raid Peter T. Breuer wrote: [] >>Let's focus on the personal machine of mine for now since it uses >>Linux software RAID and therefore on-topic here. It has /boot on a >>small RAID-1, > > This is always a VERY bad idea. /boot and /root want to be on as simple > and uncomplicated a system as possible. Moreover, they never change, so > what is the point of having a real time mirror for them? It would be > sufficient to copy them every day (which is what I do) at file system > level to another partition, if you want a spare copy for emergencies. Raid1 (mirror) is the most "trivial" raid level out there, especially having in mind that the underlying devices -- all of them -- contains (or should, in theory -- modulo the "50% chance of any difference being unnoticied" etc) exact copy of the filesystem. Also, root (and /boot -- i for one have both /boot in root in a single small filesystem) do change -- not that often but often enouth so that "newaliases problem" (when you "forgot" to backup it after a change) happens from time to time. After several years of expirience with alot of systems (and alot of various disk failure scenarios too: when you have many systems, you have good chances to see a failure ;), I now use very simple and (so far) reliable approach, which I explained here on this list before. You have several (we use 2, 3 or 4) disks which are the same (or almost: eg some 36Gb disks are really 35Gb or 37Gb; in case they're differ, "extra" space on large disk isn't used); root and /boot are on small raid1 partition which is mirrored on *every* disk; swap is on raid1; the rest (/usr, /home, /var etc) are on raid5 arrays (maybe also raid0 for some "scratch" space). This way, you have "equal" drives, and *any* drive, including boot one, may fail at any time and the system will continue working as if all where working, including reboot (except of a (very rare in fact) failure scenario when your boot disk has failed MBR or other sectors required to boot, but "the rest" of that disk is working, in which case you'll need physical presence to bring the machine up). All the drives are "symmetrical", usage patterns for all drives are the same, and due to usage of raid arrays, load is spread among them quite nicely. You're free to reorder the drives in any way you want, to replace any of them (maybe rearranging the rest if you're replacing the boot drive) and so on. Yes, root fs does not changes often, and yes it is small enouth (I use 1Gb, or 512Mb, or even 256Mb for root fs - not a big deal to allocate that space on every of 2 or 3 or 4 or 5 disks). So it isn't quite relevant how fast the filesystem will be on writes, and hence it's ok to place it on raid1 composed from 5 components. The stuff just works, it is very simple to administer/support, and does all the "backups" automatically. In case of some problem (yes I dislike any additional layers for critical system components as any layer may fail to start during boot etc), you can easily bring the system up by booting off the underlying root-raid partiton to repair the system -- all the utilities are here. More, you can boot from one disk (without raid) and try to repair root fs on another drive (if things are really screwed up), and when you're done, bring the raid up on that repaired partition and add other drives to the array. To summarize: having /boot and root on raid1 is a very *good* idea. ;) It saved our data alot of times in the past few years already. If you're worried about "silent data corruption" due to different data being read from different components of the raid array.. Well, first of all, we never saw that yet (we have quite good "testcase") (and no, I'm not saying it's impossible ofcourse). On rarely-changed filesystem, with real drives which does no silent remapping of an undeadable blocks to new place with the data on them becoming all-0s, without drives with uncontrollable write caching (quite common for IDE drives) and things like that, and with real memory (ECC I mean), where you *know* what you're writing to each disk (yes, there's also another possible cause of a problem: software errors aka bugs ;), that case with different data on different drives becomes quite.. rare. In order to be really sure, one can mount -o remount,ro / and just compare all components of the root raid, periodically. When there's more than 2 components on that array, it should be easy to determine which drive is "lying" in case of any difference. I do similar procedure on my systems during boot. >>There is nowhere that is not software RAID to put the journals, so > > Well, you can make somewhere. You only require an 8MB (one cylinder) > partition. Note scsi disks in linux only supports up to 14 partitions, which isn't sometimes sufficient even without additional partitions for journal. When you have large amount of disks (so having that "fully-symmetrical" layout as I described above becomes impractical), you can use one set of drives for data and another set of drives for journal for that data. When you only have 4 (or less) drives... And yes I'm aware of mdp devices (partitions inside the raid arrays).. but that's just another layer "which may fail": if raid5 array won't start, I at least can reconstruct filesystem image by reading chunks of data from appropriate places from all drives and try to recover that image; with any additional structure inside the array (and the lack of "loopP" aka partitioned loop devices) it becomes more and more tricky to recover any data (from this point of view, raid1 is the niciest raid level ;) Again: instead of using a partition for the journal, use (another?) raid array. This way, the system will work if the drive wich contains the journal fails. Note above about swap: in all my systems, swap is also on raid (raid1 in this case). At the first look, that can be a nonsense: having swap on raid. But we had enouth cases when due to a failed drive swap becomes corrupt (unreadable really), and the system goes havoc, *damaging* other data which was unaffected by the disk failure! With swap on raid1, the system continues working if any drive fails, which is good. (Older kernels, esp. 2.2.* series, had several probs with swap on raid, but that has been fixed now; there where other bugs fixed too (incl. bugs in ext3fs) so there should be no such damage to other data due to unreadable swap.. hopefully. But I can't trust my systems anymore after seeing (2 times in 4 years) what can happen with the data...) [] And I also want to "re-reply" to the first your message in this thread, where I was saying that "it's a nonsense that raid does not preserve write ordering". Ofcourse I mean not write ordering but working write barriers (as Neil pointed out, md subsystem does not implement write barriers directly but the concept is "emulated" by linux block subsystem). Write barriers should be sufficient to implement journalling safely. /mjt ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 12:11 ` Michael Tokarev @ 2005-01-03 14:23 ` Peter T. Breuer 2005-01-03 18:30 ` maarten ` (2 more replies) 0 siblings, 3 replies; 88+ messages in thread From: Peter T. Breuer @ 2005-01-03 14:23 UTC (permalink / raw) To: linux-raid Michael Tokarev <mjt@tls.msk.ru> wrote: > Peter T. Breuer wrote: > > This is always a VERY bad idea. /boot and /root want to be on as simple > > and uncomplicated a system as possible. Moreover, they never change, so > > what is the point of having a real time mirror for them? It would be > > sufficient to copy them every day (which is what I do) at file system > > level to another partition, if you want a spare copy for emergencies. > > Raid1 (mirror) is the most "trivial" raid level out there, especially Hi! > having in mind that the underlying devices -- all of them -- contains > (or should, in theory -- modulo the "50% chance of any difference > being unnoticied" etc) exact copy of the filesystem. Also, root (and > /boot -- i for one have both /boot in root in a single small filesystem) > do change -- not that often but often enouth so that "newaliases problem" > (when you "forgot" to backup it after a change) happens from time to time. Well, my experience is that anything "unusual" is bad: sysadmins change over the years; the guy who services the system may not be the one that built it; the "rescue" cd or floppy he has may not have MD support built into the kernel (and he probably will need a rescue cd just to get support for a raid card, if the machine has hardware raid as well as or instead of software raid). Therefore, I have learned not to build a system that is more complicated than the most simple human being that may administer it. This always works - if it breaks AND they cannot fix it, then THEY get the blame. So I "prefer" to not have a raided boot partition, but instead to rsync the root partition every day to a spare on a differet disk, or/and at the other end of the same disk. This also saves the system from sysadmin gaffes - I don't WANT an instantaneous copy of every error made by the humans. This is not to say that I do not like your ideas, expressed here. I do. I even agree with them. It is just that when they mess up the root partition, I can point to the bootloader entry that says "boot from spare root partition". And let's not get into what they can do to the labelling on the partition types - FD? Must be a mistake! > After several years of expirience with alot of systems (and alot of various > disk failure scenarios too: when you have many systems, you have good > chances to see a failure ;), I now use very simple and (so far) reliable > approach, which I explained here on this list before. You have several > (we use 2, 3 or 4) disks which are the same (or almost: eg some 36Gb Well, whenever I buy anything, I buy two. I buy two _controller_ cards, and tape the extra one inside the case. But of course I buy two machines, so that is four cards ... . And I betcha softraid sb has changed format ver the years. I am still running P100s! > disks are really 35Gb or 37Gb; in case they're differ, "extra" space > on large disk isn't used); root and /boot are on small raid1 partition > which is mirrored on *every* disk; swap is on raid1; the rest (/usr, I like this - except of course that I rsync them, not raid them. I don't mind if I have to reboot a server. Nobody will notice the tcp outage and the other one of the pair will failover for it, albeit in readonly mode, for the maximum of the few minutes required. Your swap idea is crazy, but crazy enough to be useful. YES, there used to be a swap bug which corrupted swap every so often (in 2.0? 2.2?) and meant one had to swapoff and swapon again, having first cleared all processes by an init 1 and back. Obviously that bug would bite whatever you had as media, but it still is a nice idea to have raided memory :-). > /home, /var etc) are on raid5 arrays (maybe also raid0 for some "scratch" I don't put /var on raid if I can help it. But there is nothing particularly bad about it. It is just that /var is the most active place and therefore the most likely to suffer damage of some kind, somehow. And damaged raided partitions are really not nice. Raid does not protect you against hardware corruption - on the contrary, it makes it more difficult to spot and doubles the probabilities of it happening. > space). This way, you have "equal" drives, and *any* drive, including > boot one, may fail at any time and the system will continue working > as if all where working, including reboot (except of a (very rare in > fact) failure scenario when your boot disk has failed MBR or other > sectors required to boot, but "the rest" of that disk is working, > in which case you'll need physical presence to bring the machine up). That's actually not so. Over new year I accidently booted my home server (222 days uptime!) and discovered its boot sector had evaporated. Well, maybe I moved the kernels .. anyway, it has no floppy and the nearest boot cd was an hour's journey away in the cold, on new year. Uh uh. It took me about 8 hrs, but I booted it via PXE DHCP TFTP wake-on-lan and the wireless network, from my laptop, without leaving the warm. Next time I may even know how to do it beforehand :). > All the drives are "symmetrical", usage patterns for all drives are > the same, and due to usage of raid arrays, load is spread among them > quite nicely. You're free to reorder the drives in any way you want, > to replace any of them (maybe rearranging the rest if you're > replacing the boot drive) and so on. You can do this hot? How? Oh, you must mean at reboot. > Yes, root fs does not changes often, and yes it is small enouth > (I use 1Gb, or 512Mb, or even 256Mb for root fs - not a big deal Mine are always under 256MB, but I give 512MB. > to allocate that space on every of 2 or 3 or 4 or 5 disks). So > it isn't quite relevant how fast the filesystem will be on writes, > and hence it's ok to place it on raid1 composed from 5 components. That is, uh, paranoid. > The stuff just works, it is very simple to administer/support, > and does all the "backups" automatically. Except that it doesn't - backups are not raid images. Backups are snapshots. Maybe you mean that. > In case of some problem > (yes I dislike any additional layers for critical system components > as any layer may fail to start during boot etc), you can easily > bring the system up by booting off the underlying root-raid partiton > to repair the system -- all the utilities are here. More, you can Well, you could, and I could, but I doubt if the standard tech could. > boot from one disk (without raid) and try to repair root fs on > another drive (if things are really screwed up), and when you're > done, bring the raid up on that repaired partition and add other > drives to the array. But why bother? If you didn't have raid there on root you wouldn't need to repair it. Nothing is quite as horrible as having a fubarred root partition. That's why I also always have two! But I don't see that having the copy made by raid rather than rsync wins you anything in the situaton where you have to reboot - rather, it puts off that moment to a moment of your choosing, which may be good, but is not an unqualified bonus, given the cons. > To summarize: having /boot and root on raid1 is a very *good* idea. ;) > It saved our data alot of times in the past few years already. No - it saved you from taking the system down at that moment in time. You could always have rebooted it from a spare root partition whether you had raid there or not. > If you're worried about "silent data corruption" due to different > data being read from different components of the raid array.. Well, > first of all, we never saw that yet (we have quite good "testcase") It's hard to see, and youhave to crash and come back up quite a lot to make it probable. A funky scsi cable would help you see it! > (and no, I'm not saying it's impossible ofcourse). On rarely-changed > filesystem, with real drives which does no silent remapping of an > undeadable blocks to new place with the data on them becoming all-0s, Yes, I agree. On rarely changing systems raid is a benefit, because it enables you to carry on in case the unthinkable happens and one disk vaporizes (while letting the rest of the system carry on, with much luck). On rapidly changing systems like /var I start to get a little uneasy. On /home I am quite happy with it. I wouldn't have it any other way there.. > without drives with uncontrollable write caching (quite common for > IDE drives) and things like that, and with real memory (ECC I mean), > where you *know* what you're writing to each disk (yes, there's also > another possible cause of a problem: software errors aka bugs ;), Indeed, and very frequent they are too. > that case with different data on different drives becomes quite.. > rare. In order to be really sure, one can mount -o remount,ro / > and just compare all components of the root raid, periodically. > When there's more than 2 components on that array, it should be > easy to determine which drive is "lying" in case of any difference. > I do similar procedure on my systems during boot. Well, voting is one possible procedure. I don't know if softraid does that anywhere, or attempts repairs. Neil? > >>There is nowhere that is not software RAID to put the journals, so > > > > Well, you can make somewhere. You only require an 8MB (one cylinder) > > partition. > > Note scsi disks in linux only supports up to 14 partitions, which You can use lvm (device mapper). Admittedly I was thinking of IDE. If you like I can patch scsi for 63 partitions? > isn't sometimes sufficient even without additional partitions for > journal. When you have large amount of disks (so having that > "fully-symmetrical" layout as I described above becomes impractical), > you can use one set of drives for data and another set of drives > for journal for that data. When you only have 4 (or less) drives... > > And yes I'm aware of mdp devices (partitions inside the raid > arrays).. but that's just another layer "which may fail": if > raid5 array won't start, I at least can reconstruct filesystem > image by reading chunks of data from appropriate places from > all drives and try to recover that image; with any additional Now that is just perverse. > structure inside the array (and the lack of "loopP" aka partitioned > loop devices) it becomes more and more tricky to recover any > data (from this point of view, raid1 is the niciest raid level ;) Agree. > Again: instead of using a partition for the journal, use (another?) > raid array. This way, the system will work if the drive wich > contains the journal fails. But the journal will also contain corruptions if the whole system crashes, and is rebooted. You just spent several paragraphs (?) arguing so. Do you really want those rolled forward to complete? I would rather they were rolled back! I.e. that the journal were not there - I am in favour of a zero size journal, in other words, which only acts to guarantee atomicity of FS ops (FS code on its own may do that), but which does not contain data. > Note above about swap: in all my > systems, swap is also on raid (raid1 in this case). At the first > look, that can be a nonsense: having swap on raid. But we had > enouth cases when due to a failed drive swap becomes corrupt > (unreadable really), and the system goes havoc, *damaging* > other data which was unaffected by the disk failure! With Yes, this used to be quite common when swap had that size bug. > swap on raid1, the system continues working if any drive > fails, which is good. (Older kernels, esp. 2.2.* series, > had several probs with swap on raid, but that has been fixed > now; there where other bugs fixed too (incl. bugs in ext3fs) > so there should be no such damage to other data due to > unreadable swap.. hopefully. But I can't trust my systems > anymore after seeing (2 times in 4 years) what can happen with > the data...) > > [] > > And I also want to "re-reply" to the first your message in this > thread, where I was saying that "it's a nonsense that raid does > not preserve write ordering". Ofcourse I mean not write ordering > but working write barriers (as Neil pointed out, md subsystem does > not implement write barriers directly but the concept is "emulated" > by linux block subsystem). Write barriers should be sufficient to > implement journalling safely. I am not confident that Neil did say so. I have not reexamined his post, but I got the impression that he hummed and hawed over that. I do not recall that he said that raid implements write barriers - perhaps he did. Anyway, I do not recall any code to handle "special" requests, which USED to be the kernel's barrier mechanism. Has that mechanism changed (it could have!)? What is the write barrier mechanism in the 2.6 series (and what was it in 2.4? I don't recall one at all)? I seem to recall that Neil said instead that raid acks writes only after they have been carried out on all components, which Stephen said was sufficient for ext3. OTOH we do not know if it is sufficient for reiserfs, xfs, jfs, etc. Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 14:23 ` Peter T. Breuer @ 2005-01-03 18:30 ` maarten 2005-01-03 21:36 ` Michael Tokarev 2005-01-05 5:50 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison 2 siblings, 0 replies; 88+ messages in thread From: maarten @ 2005-01-03 18:30 UTC (permalink / raw) To: linux-raid On Monday 03 January 2005 15:23, Peter T. Breuer wrote: > Michael Tokarev <mjt@tls.msk.ru> wrote: > > Peter T. Breuer wrote: > Therefore, I have learned not to build a system that is more complicated > than the most simple human being that may administer it. This always > works - if it breaks AND they cannot fix it, then THEY get the blame. > > So I "prefer" to not have a raided boot partition, but instead to rsync > the root partition every day to a spare on a differet disk, or/and at the > other end of the same disk. This also saves the system from sysadmin > gaffes - I don't WANT an instantaneous copy of every error made by the > humans. There certainly is something to be said for that... However, I do expect an admin to know about the raid system that's being used, else they would have no business being near that server in the first place. > > disks are really 35Gb or 37Gb; in case they're differ, "extra" space > > on large disk isn't used); root and /boot are on small raid1 partition > > which is mirrored on *every* disk; swap is on raid1; the rest (/usr, > > I like this - except of course that I rsync them, not raid them. I > don't mind if I have to reboot a server. Nobody will notice the tcp > outage and the other one of the pair will failover for it, albeit in > readonly mode, for the maximum of the few minutes required. I tend to agree, but it varies widely with the circumstances. I've had servers in unattended colo facilties, and your approach will not work too well there. > That's actually not so. Over new year I accidently booted my home > server (222 days uptime!) and discovered its boot sector had evaporated. We've all been there... :-( > Well, maybe I moved the kernels .. anyway, it has no floppy and the > nearest boot cd was an hour's journey away in the cold, on new year. Uh > uh. It took me about 8 hrs, but I booted it via PXE DHCP TFTP > wake-on-lan and the wireless network, from my laptop, without leaving > the warm. Congrats, but I do hope you did that for your home server...! Cause I'd have severe moral and practical difficulties selling that to a paying customer: "So instead of billing me a cab fare and two hours, you spent eight hours to fix this. And you seriously expect me to pay for those extra hours ?" > > to allocate that space on every of 2 or 3 or 4 or 5 disks). So > > it isn't quite relevant how fast the filesystem will be on writes, > > and hence it's ok to place it on raid1 composed from 5 components. > > That is, uh, paranoid. We also did use three-way raid-1 mirrors as a rule. (but I am indeed somewhat paranoid ;-) > > In case of some problem > > (yes I dislike any additional layers for critical system components > > as any layer may fail to start during boot etc), you can easily > > bring the system up by booting off the underlying root-raid partiton > > to repair the system -- all the utilities are here. More, you can > > Well, you could, and I could, but I doubt if the standard tech could. I've said it before and I'll say it again: An admin has to be competent. If not, there is little you can do. You can't have fresh MCSE people fix linux problems, and you cannot have a carpenter selling stock on wall street. A "standard tech" as you say, has a skill level that enables him to swap a drive of a hotswap server if so directed, but anything beyond that is unrealistic, and he will need adequate help (be it remote by telephone, or whatever means). Or very extensive onsite step by step documentation. > But why bother? If you didn't have raid there on root you wouldn't > need to repair it. Nothing is quite as horrible as having a > fubarred root partition. That's why I also always have two! But I > don't see that having the copy made by raid rather than rsync wins > you anything in the situaton where you have to reboot - rather, it > puts off that moment to a moment of your choosing, which may be good, > but is not an unqualified bonus, given the cons. Both approaches have their merits. In one case the danger lies in not having updated the rsync mirror recently enough, in the other a rogue change will affect all your mirrors. Without further info on the specific circumstances no choice can be made, it really depends on too many factors. > > And yes I'm aware of mdp devices (partitions inside the raid > > arrays).. but that's just another layer "which may fail": if > > raid5 array won't start, I at least can reconstruct filesystem > > image by reading chunks of data from appropriate places from > > all drives and try to recover that image; with any additional > > Now that is just perverse. Not neccessarily. I've had to rely on using dd_rescue to get data back at some point is time. In such scenarios, any additional layer can quickly complicate things beyond reasonable recourse. As you noted yourself, keeping a backup stategy can be hard work. ;-| > > Note above about swap: in all my > > systems, swap is also on raid (raid1 in this case). At the first > > look, that can be a nonsense: having swap on raid. But we had > > enouth cases when due to a failed drive swap becomes corrupt > > (unreadable really), and the system goes havoc, *damaging* > > other data which was unaffected by the disk failure! With > > Yes, this used to be quite common when swap had that size bug. When you have swap on a failed disk, often the safer way is to stop the machine by using the reset button instead of attempting a shutdown. The shutdown would probably fail halfway through anyway... Maarten ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-03 14:23 ` Peter T. Breuer 2005-01-03 18:30 ` maarten @ 2005-01-03 21:36 ` Michael Tokarev 2005-01-05 5:50 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison 2 siblings, 0 replies; 88+ messages in thread From: Michael Tokarev @ 2005-01-03 21:36 UTC (permalink / raw) To: linux-raid Peter T. Breuer wrote: > Michael Tokarev <mjt@tls.msk.ru> wrote: > >>Peter T. Breuer wrote: >> >>>This is always a VERY bad idea. /boot and /root want to be on as simple >>>and uncomplicated a system as possible.... [] > Well, my experience is that anything "unusual" is bad: sysadmins change > over the years; the guy who services the system may not be the one that > built it; the "rescue" cd or floppy he has may not have MD support > built into the kernel (and he probably will need a rescue cd just to get > support for a raid card, if the machine has hardware raid as well as or > instead of software raid). It is trivial to learn (or teach) that you can boot with root=/dev/sda1 instead of root=/dev/md1. All our technicians knows that. Indeed, most will not be able to recover the system in most cases anyway IF root raid will not start "by its own", but that's a different matter entirely. Sometimes it may be a trivial case (like we had just a few months ago: I asked our guy to go to the remote office to replace a drive and gave him a replacement, which contained raid component in the first partition.. and "stupid boot code" (Mine!.. sort of ;) descided to bring THAT array instead of the real raid array on original disks because the event counter was greather. So we ended up booting with root=/dev/sda1 ro init=/bin/sh and just zeroing the partition in the new drive.. which I simple forgot to do in the first place. All by phone, it took about 5 minutes to complete the whole task and bring the server up after the reboot that he performed when went there.. total downtime was about 15 minutes. After which, I logged into the system remotely, verified data integrity of existing arrays and added the new disk to all the arrays -- while the system was in production (just a bit slow) and our guy was having some tea (or whatever... ;) before going back. Having several root partitions is a good thing. I rarely need to tweak the boot process (that to say: it rarely fails, except of several stupid cases like the above; And when it fails, it is even possible to bring the system up while on phone with any non- technicial "monkey" from their remote office who don't even know latin letters (we're in russia so english isn't our native language; when describing what to do I sometimes tell to press "cyrillic" keys on the keyboard to produce latin characters... ;) And yes, any bug that "crashes" this damn root system will mess with the whole thing, with all mirrors.. which is a fatal error, so to say. Well.. if you can't trust the processor for example to correctly multiple 2*2 and want to use two (or more) processors just to be sure one isn't lying.. such systems do exists too, but hey, they aren't cheap at all... ;) > Therefore, I have learned not to build a system that is more complicated > than the most simple human being that may administer it. This always > works - if it breaks AND they cannot fix it, then THEY get the blame. Perhaps our conditions are a bit different.. who kows. Raid1 IS simple -- both in implementation and in usage. Our guys are trained very hard to ensure they will NOT try to mess things up unless they're absolutely sure what they're doing. And I don't care who to blame (me or my technicians or whatever): we all will lose money in case of serious problems (we're managing networks/servers for $customers, they're paying us for the system to work with at most one business day downtime in case of any problem, with all their data intact -- we're speaking of remote locations here)... etc.. ;) If you don't trust your guys to do right (or to ask and *understand* when they don't know), or if your guys are doing mistakes all over -- perhaps it's a time to hire them off? ;) > And let's not get into what they can do to the labelling on the > partition types - FD? Must be a mistake! BTW, letting the kernel to start arrays is somewhat.. wrong (i mean the auto-detection and that "FD" type). Again, I learned it the hard way ;) The best is to have initrd and pass GUUID of your raid array into it (this is what I *don't* do currently ;) [] > Well, whenever I buy anything, I buy two. I buy two _controller_ cards, > and tape the extra one inside the case. But of course I buy two > machines, so that is four cards ... . Oh well... that all depends on the amount of $money. We have several "double-machines" too here, but only several. The rest of systems are single, with a single (usually onboard) scsi controller. > And I betcha softraid sb has changed format ver the years. I am still > running P100s! It isn't difficult to re-create the arrays, even remotely (if you're accurate enouth ofcourse). Not that it is needed too often either... ;) >>disks are really 35Gb or 37Gb; in case they're differ, "extra" space >>on large disk isn't used); root and /boot are on small raid1 partition >>which is mirrored on *every* disk; swap is on raid1; the rest (/usr, > > I like this - except of course that I rsync them, not raid them. I > don't mind if I have to reboot a server. Nobody will notice the tcp > outage and the other one of the pair will failover for it, albeit in > readonly mode, for the maximum of the few minutes required. Depends alot of your usage patterns, or tasks running, or other conditions (esp. physical presense). I for one can't afford rebooting many of them at all, for a very simple reason: many of them are on a very bad dialups, and some are several 100s KMs (or miles for that matter) away... ;) And also most of the boxes are running oracle with quite complex business rules, they're calculating some reports which sometimes takes quite some time to complete, esp at the end of the year. For this very reason -- they're all quite far away from me, out of reach -- I tend to ensure they WILL boot and will be able to dial out and bring that damn tunnel so I can log in and repair whatever is needed... ;) > Your swap idea is crazy, but crazy enough to be useful. YES, there used > to be a swap bug which corrupted swap every so often (in 2.0? 2.2?) and > meant one had to swapoff and swapon again, having first cleared all > processes by an init 1 and back. Obviously that bug would bite whatever > you had as media, but it still is a nice idea to have raided memory > :-). It sounds crazy at the first look, I wrote just that. But it helps to ensure the system is running as if nothing happened. I just receive email telling me node X has one array degraded, I log in there remotely, diagnose the problem and do whatever is needed (remapping the bad block, or arranging to send a guy there with a replacement drive when there will be such a chance.. whatever). The system continues working just fine for all that time (UNLESS another drive fails too ofcourse -- all the raid5 arrays will be dead and "urgent help" will be needed in that case -- at *that* time only it will be possible to reboot as many times as needed). The key point with my setup is that the system will continue working in case of any single drive failure. If I need more protection, I'll use raid6 or raid10 (or raid1 on several drives, whatever) so the system will continue working in case of multiple drive failures. But it will still be running, giving me a time/chance to diagnose the prob and find good schedule for our guys to come and fix things if needed -- maybe "right now", maybe "next week" or even "next month", depending on the exact problem. >>/home, /var etc) are on raid5 arrays (maybe also raid0 for some "scratch" > > I don't put /var on raid if I can help it. But there is nothing > particularly bad about it. It is just that /var is the most active > place and therefore the most likely to suffer damage of some kind, somehow. > And damaged raided partitions are really not nice. Raid does not > protect you against hardware corruption - on the contrary, it makes it > more difficult to spot and doubles the probabilities of it happening. Heh.. In our case, the most active (and largest) filesystem is /oracle ;) And yes I know using raid5 for a database isn't quite a good idea.. but that's entirely different topic (and nowadays, when raid5 checksumming is very cheap in terms of cpu, maybe it isn't that bad anymore ;) Yes raid5 is complex beast compared to raid1. Yes, raid5 may not be appropriate for some workloads. And still -- yes, this all is about a compromise in money one have and what he can afford to lose and for what duration, and how much (money again, but in this our case that'll be our money, not $client money) one can spend to fix the problem IF it will need to be fixed the "hard way" (so far we have two cases which required restoration the hard way, one was because $client used cheap hardware instead of our recommendations and non-ECC memory failed -- in that case, according to contract, it was $client who paid for the restore; and second was due to software error (oracle bug, now fixed), but we had "remote backup" of the database (it's a large distributed system and the data is replicated among several nodes), so I exported the "backup" and just re-initialized their database. And yes, we simulated various recovery scenarios in our own office on a toy data, to be sure we will be able to recover the thing the "hard way" if that'll be needed). >>space). This way, you have "equal" drives, and *any* drive, including >>boot one, may fail at any time and the system will continue working >>as if all where working, including reboot (except of a (very rare in >>fact) failure scenario when your boot disk has failed MBR or other >>sectors required to boot, but "the rest" of that disk is working, >>in which case you'll need physical presence to bring the machine up). > > That's actually not so. Over new year I accidently booted my home > server (222 days uptime!) and discovered its boot sector had evaporated. Uh-oh. So just replace the first and second (or third, 4th) disks and boot from that... ;) Yes that can happen -- after all, lilo may have a bug, or a bios, or mbr code... But that's again about whenever you can afford to "trust the processor", above. Yes again, there are humans which tend to make mistakes (I made alot of mistakes in my life, oh, alot of them!, once I even formatted the "wrong disk" and lost half a year of our work.. and started doing some backups finally ;). I don't think there's anything that can protect against human mistakes -- I mean humans who manage the system, not who use it. > Well, maybe I moved the kernels .. anyway, it has no floppy and the > nearest boot cd was an hour's journey away in the cold, on new year. Uh > uh. It took me about 8 hrs, but I booted it via PXE DHCP TFTP > wake-on-lan and the wireless network, from my laptop, without leaving > the warm. Heh. Well, I always have bootable cd or a floppy, just in case. Not to say I really used that at least once (but I do know it contains all tools needed for boot and recovery). Yes, shit happens (tm) too... ;) >>All the drives are "symmetrical", usage patterns for all drives are >>the same, and due to usage of raid arrays, load is spread among them >>quite nicely. You're free to reorder the drives in any way you want, >>to replace any of them (maybe rearranging the rest if you're >>replacing the boot drive) and so on. > > You can do this hot? How? Oh, you must mean at reboot. Yes -- here I was speaking about the "worst case", when boot fails for whatever reason. I never needed the "boot floppy" just because of this: I can make any drive bootable just by changing the SCSI IDs, and the system will not notice anything changed (it will in fact: somewhere in dmesg you'll find "device xx was yy before" message from md, that's basically all). 99% of the systems we manage don't have hot-swap drives, so in case a drive have to be replaced, reboot is needed anyway. The nice thing is that I don't care which drive is being replaced (except of the boot one -- in that case our guys knows they have to set up another - any - drive as bootable), and when system boots, I just do for f in 1 2 3 5 6 7 8 9; do mdadm --add /dev/md$f /dev/sdX$f done (note the device numbering too: mdN is built of sd[abc..]N) and be done with that (not really *that* simple, I prefer to verify integrity of other drives before adding the new one, but that's just details). >>Yes, root fs does not changes often, and yes it is small enouth >>(I use 1Gb, or 512Mb, or even 256Mb for root fs - not a big deal > > Mine are always under 256MB, but I give 512MB. > >>to allocate that space on every of 2 or 3 or 4 or 5 disks). So >>it isn't quite relevant how fast the filesystem will be on writes, >>and hence it's ok to place it on raid1 composed from 5 components. > > That is, uh, paranoid. The point isn't about paranoia, it's about simplicitly. Or symmetry, which leads to that same simplicity again. They're all the same and can be used interchangeable, period. For larger amount of disks, such a layout may be not as practical, but it should work find with up to, say, 6 disks (but I'm somewhat afraid to use raid5 with 6 components, as the chance to have two failed drives, which is "fatal" for raid5, increases). >>The stuff just works, it is very simple to administer/support, >>and does all the "backups" automatically. > > Except that it doesn't - backups are not raid images. Backups are > snapshots. Maybe you mean that. "Live" backups ;)... with all the human errors on them too. Raid1 can't manage snapshots. >>In case of some problem >>(yes I dislike any additional layers for critical system components >>as any layer may fail to start during boot etc), you can easily >>bring the system up by booting off the underlying root-raid partiton >>to repair the system -- all the utilities are here. More, you can [] >>boot from one disk (without raid) and try to repair root fs on >>another drive (if things are really screwed up), and when you're >>done, bring the raid up on that repaired partition and add other >>drives to the array. > > But why bother? If you didn't have raid there on root you wouldn't > need to repair it. See above for a (silly) example -- wrong replacement disk ;) And indeed that's silly example. I once had another "test case" to deal with, when my root raid was composed of 3 components and each had different event counter, for whatever reason (I don't remember the details already) -- raid1 was refusing to start. It was with 2.2.something kernel -- things changed since that time alot, but the "testcase" still was here (it happened on our test machine in office). > Nothing is quite as horrible as having a > fubarred root partition. That's why I also always have two! But I > don't see that having the copy made by raid rather than rsync wins > you anything in the situaton where you have to reboot - rather, it > puts off that moment to a moment of your choosing, which may be good, > but is not an unqualified bonus, given the cons. It helps keeping the machine running *and* bootable even after losing the boot drive (for some reason our drives fails completely most of the time, instead of developing bad sectors; so next reboot (our remote offices have somewhat unstable power and gets rebooted from time to time) will be from the 2nd drive...). It saves you from the "newaliases" problem ("forgot to rsync" maybe silly, but even after a small change, remembering/repeating it after the recovery again (if the crash happened before rsync but after the change) -- I'm lazy ;) Yes this technique places more "load" on the administrator, because every his mistake gets mirrored automatically and immediately... There was a funny case with another box I installed for myself. It's in NY, USA (I'm in Russia, remember?), and there's noone at the colo facility who knows linux well enouth, and the box in question has no serial console (esp bios support). After installing the system (there was some quick-n-dirty linux "preinstalled" by the colo guys -- thanks god they created two partitions (2nd one was swap), -- I loaded another distro to the swap partition, rebooted and re-partitioned the rest moving /var etc into real place... Fun by itself, but that's not the point. After successeful install, "in a hurry", I did some equivalent of... rm -rf /* ! Just a typo, but WHAT typo! ;) I was doing all that from home over a dialup. I hit Ctrl-C when it wiped out /boot, /bin (mknod! chmod! cat!), /etc, /dev, and started removing /home (which was quite large). Damn fast system!.. ;) I had only one ssh window opened... With the help from uudecode (wich is in /usr/bin) and alot of cut-n-pasteing, I was able to create basic utilities on that system -- took them from asmutils site. Restored /dev somehow, cut-n-pasted small wget, and slowly reinstalled the whole system again (it's debian). Took me 3 damn hours of a very hard work to reinstall and configure and to ensure everything is ok to reboot -- I had no other chance to correct any boot mistakes, and, having in mind our bad phone lines, the whole procedure was looking almost impossible. I asked a friend of mine to log in before the reboot and to check if everything looks ok and it will actually boot. But it just worked. After that excersise, I was sleeping for more than 12 hours in a row, because I was really tired. That to say: ugh-oh, damn humans, there's nothing here to protect the poor machines from them, they always will find their ways to screw things up... ;) Yes, having non-raid rsynced backup helps in that case, and yes, such a case is damn rare... Dunno whichever is "right". After all, nothing stops to have BOTH mirrored AND backed-up root filesystem... ;) >>To summarize: having /boot and root on raid1 is a very *good* idea. ;) >>It saved our data alot of times in the past few years already. > > No - it saved you from taking the system down at that moment in time. > You could always have rebooted it from a spare root partition whether > you had raid there or not. Quite a problem when the system is away from you... ;) >>If you're worried about "silent data corruption" due to different >>data being read from different components of the raid array.. Well, >>first of all, we never saw that yet (we have quite good "testcase") > > It's hard to see, and youhave to crash and come back up quite a lot to > make it probable. A funky scsi cable would help you see it! We did alot of testing by our own too. Sure that's not cover every possible case. Yet all of the 200+ systems we manage are working just fine since 1999, with no single "bad" failure so far (I already mentioned 2 cases which aren't really count for obvious reasons). [] >>without drives with uncontrollable write caching (quite common for >>IDE drives) and things like that, and with real memory (ECC I mean), >>where you *know* what you're writing to each disk (yes, there's also >>another possible cause of a problem: software errors aka bugs ;), > > Indeed, and very frequent they are too. > >>that case with different data on different drives becomes quite.. >>rare. In order to be really sure, one can mount -o remount,ro / >>and just compare all components of the root raid, periodically. >>When there's more than 2 components on that array, it should be >>easy to determine which drive is "lying" in case of any difference. >>I do similar procedure on my systems during boot. > > Well, voting is one possible procedure. I don't know if softraid does > that anywhere, or attempts repairs. > > Neil? It does not do that.. yet. >>>>There is nowhere that is not software RAID to put the journals, so >>> >>>Well, you can make somewhere. You only require an 8MB (one cylinder) >>>partition. >> >>Note scsi disks in linux only supports up to 14 partitions, which > > You can use lvm (device mapper). Admittedly I was thinking of IDE. The same problem as with partitionable raid arrays, and with your statement about simplicity: lvm layout may be quite complex and quite difficult to repair *if* something goes really wrong. And.. oh, no IDE please, thanks alot!.. :) > If you like I can patch scsi for 63 partitions? I did that once myself - patched 2.2.something to have 63 partitions on scsi disks. But had alot of problems with other software after that, because some software assumes device 8,16 is sdb, and because I always have to remember to boot the "right" kernel. Nowadays, for me at least, things aren't that bad anymore. I was using (trying to anyway) raw devices with oracle instead of using the filesystem (oracle works better that way because of no double- caching in oracle and in the filesystem). Now there's such a thing as O_DIRECT which works just as good. Still, we use 8 partitions on most systems, and having single "journal partition" means we will need 16 partitions which is more than linux allows. >>[] I at least can reconstruct filesystem >>image by reading chunks of data from appropriate places from >>all drives and try to recover that image; with any additional > > Now that is just perverse. *If* things really goes wrong. I managed to restore fubared raid5 once this way, several years ago. Not that the approach is "practical" or "easy", but if you must and the bad has already happened... ;) [] >>Again: instead of using a partition for the journal, use (another?) >>raid array. This way, the system will work if the drive wich >>contains the journal fails. > > But the journal will also contain corruptions if the whole system > crashes, and is rebooted. You just spent several paragraphs (?) arguing > so. Do you really want those rolled forward to complete? I would > rather they were rolled back! I.e. that the journal were not there - > I am in favour of a zero size journal, in other words, which only acts > to guarantee atomicity of FS ops (FS code on its own may do that), but > which does not contain data. That's another case again. Trust your cpu? Trust the kernel? If the system can go havoc for some random reason and throw your (overwise prefectly valid) data away, there's nothing to protect it.. except of good backup, and, ofcourse, fixing the damn bug. And it's really irrelevant in this case whenever we have journal at all or not. If there IS a journal (my main reason to use it is that sometimes ext2fs can't repair on reboot without prompting (which is about to unacceptable to me because the system is remote and I need it to boot and "phone home" for repair), while with ext3 we had no case (yet) when it was unable to boot without human intervention), again, in my "usage case", it should be safe against disk failures, ie, the system should continue working the the drive where the journal is gets lost or develops bad sectors. For the same reason... ;) >>[] >> >>And I also want to "re-reply" to the first your message in this >>thread, where I was saying that "it's a nonsense that raid does >>not preserve write ordering". Ofcourse I mean not write ordering >>but working write barriers (as Neil pointed out, md subsystem does >>not implement write barriers directly but the concept is "emulated" >>by linux block subsystem). Write barriers should be sufficient to >>implement journalling safely. > > I am not confident that Neil did say so. I have not reexamined his > post, but I got the impression that he hummed and hawed over that. > I do not recall that he said that raid implements write barriers - > perhaps he did. Anyway, I do not recall any code to handle "special" > requests, which USED to be the kernel's barrier mechanism. Has that > mechanism changed (it could have!)? "Too bad" I haven't looked at the code *at all* (almost, really) ;) I saw numerous discussions here and there, but it's difficult to understand *that* amount of code with all the "edge cases". I just "believe" there's some way to know the data has been written and that it indeed has been written; and I know this is sufficient to build a "safe" (in some sense) filesystem (or whatever) based on this; and what ext3 IS that "safe" filesystem. Just believe, that's all... ;) BTW, thanks for a good discussion. Seriously. It's very rare one can see this level of expirience as you demonstrate. /mjt ^ permalink raw reply [flat|nested] 88+ messages in thread
* Debian Sarge mdadm raid 10 assembling at boot problem 2005-01-03 14:23 ` Peter T. Breuer 2005-01-03 18:30 ` maarten 2005-01-03 21:36 ` Michael Tokarev @ 2005-01-05 5:50 ` Roger Ellison 2005-01-05 13:41 ` Michael Tokarev 2 siblings, 1 reply; 88+ messages in thread From: Roger Ellison @ 2005-01-05 5:50 UTC (permalink / raw) To: linux-raid I've been having an enjoyable time tinkering with software raid with Sarge and the RC2 installer. The system boots fine with Raid 1 for /boot and Raid 5 for /. I decided to experiment with Raid 10 for /opt since there's nothing there to destroy :). Using mdadm to create a Raid 0 array from two Raid 1 arrays was simple enough, but getting the Raid 10 array activated at boot isn't working well. I used update-rc.d to add the symlinks to mdadm-raid using the defaults, but the Raid 10 array isn't assembled at boot time. After getting kicked to a root shell, if I check /proc/mdstat only md1 (/) is started. After running mdadm-raid start, md0 (/boot), md2, and md3 start. If I run mdadm-raid start again md4 (/opt) starts. Fsck'ing the newly assembled arrays before successfully issuing 'mount -a' shows no filesystem errors. I'm at a loss and haven't found any similar issue mentions on this list or the debian-users list. Here's mdadm.conf: DEVICE partitions DEVICE /dev/md* ARRAY /dev/md4 level=raid0 num-devices=2 UUID=bf3456d3:2af15cc9:18d816bf:d630c183 devices=/dev/md2,/dev/md3 ARRAY /dev/md3 level=raid1 num-devices=2 UUID=a51da14e:41eb27ad:b6eefb94:21fcdc95 devices=/dev/sdb5,/dev/sde5 ARRAY /dev/md2 level=raid1 num-devices=2 UUID=ac25a75b:3437d397:c00f83a3:71ea45de devices=/dev/sda5,/dev/sdc5 ARRAY /dev/md1 level=raid5 num-devices=4 spares=1 UUID=efec4ae2:1e74d648:85582946:feb98f0c devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sde3,/dev/sdd3 ARRAY /dev/md0 level=raid1 num-devices=4 spares=1 UUID=04209b62:6e46b584:06ec149f:97128bfb devices=/dev/sda1,/dev/sdb1,/dev/sdc1,/dev/sde1,/dev/sdd1 Roger ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: Debian Sarge mdadm raid 10 assembling at boot problem 2005-01-05 5:50 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison @ 2005-01-05 13:41 ` Michael Tokarev 2005-01-05 13:57 ` [help] [I2O] Adaptec 2400A on FC3 Angelo Piraino 2005-01-05 19:15 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison 0 siblings, 2 replies; 88+ messages in thread From: Michael Tokarev @ 2005-01-05 13:41 UTC (permalink / raw) To: Roger Ellison; +Cc: linux-raid [Please don't start new thread by replying to another message.] Roger Ellison wrote: > I've been having an enjoyable time tinkering with software raid with > Sarge and the RC2 installer. The system boots fine with Raid 1 for > /boot and Raid 5 for /. I decided to experiment with Raid 10 for /opt > since there's nothing there to destroy :). Using mdadm to create a Raid > 0 array from two Raid 1 arrays was simple enough, but getting the Raid Note there's special raid10 module in recent kernels (and supported by recent mdadm). I don't think it's very stable yet, but.. JFYI ;) > 10 array activated at boot isn't working well. I used update-rc.d to > add the symlinks to mdadm-raid using the defaults, but the Raid 10 array Shouldn't the links be made automatically when installing mdadm? Also, make sure you're using recent debian package of mdadm -- earlier versions was.. with issues concerning assembling the arrays (a problem specific to debian mdadm-raid scripts). Make sure AUTOSTART is set to true in /etc/default/mdadm (I'm not sure if that's really `AUTOSTART' and `true', you can look at the file and/or use dpkg-reconfigure mdadm to set that). > isn't assembled at boot time. After getting kicked to a root shell, if > I check /proc/mdstat only md1 (/) is started. After running mdadm-raid > start, md0 (/boot), md2, and md3 start. If I run mdadm-raid start again > md4 (/opt) starts. Fsck'ing the newly assembled arrays before > successfully issuing 'mount -a' shows no filesystem errors. I'm at a > loss and haven't found any similar issue mentions on this list or the > debian-users list. Here's mdadm.conf: You have two problems. First of all, mdadm-raid should be started at very early in the boot process, and mdadm package post-install scripts ensures this (you added mdadm-raid links at default order which is 20; but it should run before filesystem mounts etc, nearly 01 or something). Ditto for stop scripts -- at the very end, after umounting the filesystems. Take a look at /var/lib/dpkg/info/mdadm.postinst -- it sets up the links properly. When you correct this, your system will go further in boot process... ;) And second problem is the order of lines in mdadm.conf. [edited a bit] > DEVICE partitions > DEVICE /dev/md* > ARRAY /dev/md4 level=raid0 num-devices=2 devices=/dev/md2,/dev/md3 > ARRAY /dev/md3 level=raid1 num-devices=2 devices=/dev/sdb5,/dev/sde5 > ARRAY /dev/md2 level=raid1 num-devices=2 devices=/dev/sda5,/dev/sdc5 Re-order the lines so that md4 will be listed AFTER all it's components. Mdadm tries to assemble them in turn as they're listed in mdadm.conf. But at the time when it tries to start md4, it's components aren't here yet so it fails. HTH. /mjt ^ permalink raw reply [flat|nested] 88+ messages in thread
* [help] [I2O] Adaptec 2400A on FC3 2005-01-05 13:41 ` Michael Tokarev @ 2005-01-05 13:57 ` Angelo Piraino 2005-01-05 19:15 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison 1 sibling, 0 replies; 88+ messages in thread From: Angelo Piraino @ 2005-01-05 13:57 UTC (permalink / raw) To: linux-raid I'm having some troubles with an Adaptec 2400A ATA Raid controller on FC3. Everything worked fine during installation and Operating System recognized automatically the RAID card. I also installed raidutils-0.0.4 from http://i2o.shadowconnect.com, but when I try to use the command raidutil this is the result: > [root@omissis ~]# raidutil -L > osdIOrequest : File /dev/dpti17 Could Not Be OpenedEngine connect > failed: COMPATIBILITY number I need to manage the raid card at least for display the status of the RAID array. Can anybody help me? Thanks Angelo Piraino Linux FC3 on PIII 450MHz - chipset Intel P2BF - 256Mb Ram - Ata Raid Adaptec 2400A ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: Debian Sarge mdadm raid 10 assembling at boot problem 2005-01-05 13:41 ` Michael Tokarev 2005-01-05 13:57 ` [help] [I2O] Adaptec 2400A on FC3 Angelo Piraino @ 2005-01-05 19:15 ` Roger Ellison 1 sibling, 0 replies; 88+ messages in thread From: Roger Ellison @ 2005-01-05 19:15 UTC (permalink / raw) To: linux-raid On Wed, 2005-01-05 at 08:41, Michael Tokarev wrote: > [Please don't start new thread by replying to another message.] > > Roger Ellison wrote: > > I've been having an enjoyable time tinkering with software raid with > > Sarge and the RC2 installer. The system boots fine with Raid 1 for > > /boot and Raid 5 for /. I decided to experiment with Raid 10 for /opt > > since there's nothing there to destroy :). Using mdadm to create a Raid > > 0 array from two Raid 1 arrays was simple enough, but getting the Raid > > Note there's special raid10 module in recent kernels (and supported by > recent mdadm). I don't think it's very stable yet, but.. JFYI ;) I didn't see Raid 10 mentioned in the mdadm man page. Do you have the command line syntax handy? I don't have access to the machine now, but I believe it's mdadm version 1.7 (from August '04). > > > 10 array activated at boot isn't working well. I used update-rc.d to > > add the symlinks to mdadm-raid using the defaults, but the Raid 10 array > > Shouldn't the links be made automatically when installing mdadm? > Also, make sure you're using recent debian package of mdadm -- > earlier versions was.. with issues concerning assembling the > arrays (a problem specific to debian mdadm-raid scripts). > Make sure AUTOSTART is set to true in /etc/default/mdadm > (I'm not sure if that's really `AUTOSTART' and `true', > you can look at the file and/or use dpkg-reconfigure mdadm > to set that). > The symlinks on Sarge installation were: rc0.d --> S50mdadm-raid rc6.d --> S50mdadm-raid rcS.d --> S25mdadm-raid I removed them before running 'update-rc.d'. > > isn't assembled at boot time. After getting kicked to a root shell, if > > I check /proc/mdstat only md1 (/) is started. After running mdadm-raid > > start, md0 (/boot), md2, and md3 start. If I run mdadm-raid start again > > md4 (/opt) starts. Fsck'ing the newly assembled arrays before > > successfully issuing 'mount -a' shows no filesystem errors. I'm at a > > loss and haven't found any similar issue mentions on this list or the > > debian-users list. Here's mdadm.conf: > > You have two problems. > First of all, mdadm-raid should be started at very early in the > boot process, and mdadm package post-install scripts ensures this > (you added mdadm-raid links at default order which is 20; but > it should run before filesystem mounts etc, nearly 01 or something). > Ditto for stop scripts -- at the very end, after umounting the > filesystems. Take a look at /var/lib/dpkg/info/mdadm.postinst -- > it sets up the links properly. When you correct this, your system > will go further in boot process... ;) > > And second problem is the order of lines in mdadm.conf. > > [edited a bit] > > DEVICE partitions > > DEVICE /dev/md* > > ARRAY /dev/md4 level=raid0 num-devices=2 devices=/dev/md2,/dev/md3 > > ARRAY /dev/md3 level=raid1 num-devices=2 devices=/dev/sdb5,/dev/sde5 > > ARRAY /dev/md2 level=raid1 num-devices=2 devices=/dev/sda5,/dev/sdc5 > > Re-order the lines so that md4 will be listed AFTER all it's > components. Mdadm tries to assemble them in turn as they're > listed in mdadm.conf. But at the time when it tries to start > md4, it's components aren't here yet so it fails. > Reordering the ARRAY entries has no effect. 'mdadm-raid start' has to be run twice, same as before. Changing the start symlinks from '20' to '13' (just after syslogd) doesn't help. (sigh). > HTH. > > /mjt > - Roger ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-02 19:42 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith 2005-01-02 20:18 ` Peter T. Breuer @ 2005-01-05 9:56 ` Andy Smith 2005-01-05 10:44 ` Alvin Oga 1 sibling, 1 reply; 88+ messages in thread From: Andy Smith @ 2005-01-05 9:56 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 2767 bytes --] As a small request please could those who are posting opinions on the following: - What level of schooling any person's mathematical ability resembles - Whether Peter's computing environment is sane or not - IQ level and admin skills of various persons - Issues of p2p, rootkits, unruly students, etc. etc. Plus various other personal attacks and ad hominem: Please consider if what you are writing is relevant to this list (linux-raid) or the subject of this thread (whether it is wise to put the journal for an ext3 filesystem internal to the filesystem when it is on a RAID-1 mirror). Obviously I am not a moderator or even anyone of any influence, but the majority of text I am now seeing in this thread is not useful to read and (since it is archived) may actually be giving a bad impression of its poster for all time. From what I can understand of the thread so far, Peter is saying the following: RAID mirrors are susceptible to increasing undetectable inconsistencies because, as we all know, filesystems sustain corruption over time. On a filesystem that runs from one disk, corruption serious enough to affect the stability of the file system will do so and so will be detected. As more disks are added to the mirror, the probability of that corruption never being seen naturally goes up. Peter personally does not put the journal inside the mirror because if he ever came to need to use the journal and found that it was corrupted, it could risk his whole filesystem. Peter prefers to put the journal on a separate device that is not mirrored. I am not trying to put words into your mouth Peter, just trying to summarise what your points are. If I haven't represented your views correctly then by all means correct me but please try to do so succinctly and informatively. Now, others are saying in response to this, things like: Spontaneous corruption is rare compared to outright or catastrophic device failure, and although it is more likely to go unnoticed with RAID mirrors, while it IS unnoticed, this presumably correct data is also being rewritten back to the filesystem. Mirrors help protect against the more common complete device failure and so a journal should surely be on a mirror since if you lose the journal then the machine needs to go down anyway. It is unavailability of the server we're trying to avoid; consistency of the data can be protected with regular backups and possibly measured with other methods like md5sum. Discuss? ;) [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 9:56 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith @ 2005-01-05 10:44 ` Alvin Oga 2005-01-05 10:56 ` Brad Campbell 0 siblings, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-05 10:44 UTC (permalink / raw) To: Andy Smith; +Cc: linux-raid hi ya andy good summary ... thanx.. one more item :-) On Wed, 5 Jan 2005, Andy Smith wrote: .. > From what I can understand of the thread so far, Peter is saying the > following: > > RAID mirrors are susceptible to increasing undetectable > inconsistencies because, as we all know, filesystems sustain > corruption over time. > > On a filesystem that runs from one disk, corruption serious > enough to affect the stability of the file system will do so > and so will be detected. As more disks are added to the > mirror, the probability of that corruption never being seen > naturally goes up. > > Peter personally does not put the journal inside the mirror > because if he ever came to need to use the journal and found > that it was corrupted, it could risk his whole filesystem. > Peter prefers to put the journal on a separate device that > is not mirrored. > > I am not trying to put words into your mouth Peter, just trying to > summarise what your points are. If I haven't represented your views > correctly then by all means correct me but please try to do so > succinctly and informatively. > > Now, others are saying in response to this, things like: > > Spontaneous corruption is rare compared to outright or > catastrophic device failure, and although it is more > likely to go unnoticed with RAID mirrors, while it IS > unnoticed, this presumably correct data is also being rewritten > back to the filesystem. > > Mirrors help protect against the more common complete device > failure and so a journal should surely be on a mirror since > if you lose the journal then the machine needs to go down > anyway. It is unavailability of the server we're trying to > avoid; consistency of the data can be protected with regular > backups and possibly measured with other methods like > md5sum. some other issues ... how one can detect failures, errors would be completely up to the tools they use ... various tools does specific functions and cannot tell you anything about any other causes of the problems for swap ... i personally don't see any reason to mirror swap partitions ... - once the system dies, ( power off ), all temp data is useless unless one continues from a coredump ( from the same state as when it went down initially ) if a disk did fail, die, error, hiccup, then whatever cause the problem can also affect the data and the metadata and the parity and the "mirror" - which set of "bytes" on the disk "raid" trust to restore from is up to the code and its predefined set of assumptions of various failure modes - partially written data is very bad thing to have unless you know "exactly why and how if failed/eerrored, there is no sane way to bet the house on which data is more correct than the other - i'm excluding bad memory, bad cpu, bad power supply from the lsit of possible problems and yes, bad (generic) memory has corrupted my systems once in 10 yrs... have fun alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 10:44 ` Alvin Oga @ 2005-01-05 10:56 ` Brad Campbell 2005-01-05 11:39 ` Alvin Oga ` (2 more replies) 0 siblings, 3 replies; 88+ messages in thread From: Brad Campbell @ 2005-01-05 10:56 UTC (permalink / raw) To: Alvin Oga; +Cc: Andy Smith, linux-raid Alvin Oga wrote: > > for swap ... i personally don't see any reason to mirror > swap partitions ... > - once the system dies, ( power off ), all temp > data is useless unless one continues from a coredump > ( from the same state as when it went down initially ) I beg to differ on this one. Having spend several weeks tracking down random processes dying on a machine that turned out to be a bad sector in the swap partition, I have had great results by running swap on a RAID-1. If you develop a bad sector in a non-mirrored swap, bad things happen indeterminately and can be a royal PITA to chase down. It's just a little extra piece of mind. Regards, Brad ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 10:56 ` Brad Campbell @ 2005-01-05 11:39 ` Alvin Oga 2005-01-05 12:02 ` Brad Campbell 2005-01-05 14:12 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Erik Mouw 2005-01-05 15:17 ` Guy 2 siblings, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-05 11:39 UTC (permalink / raw) To: Brad Campbell; +Cc: Andy Smith, linux-raid hi ya brad On Wed, 5 Jan 2005, Brad Campbell wrote: > Alvin Oga wrote: > > > > for swap ... i personally don't see any reason to mirror > > swap partitions ... > > - once the system dies, ( power off ), all temp > > data is useless unless one continues from a coredump > > ( from the same state as when it went down initially ) > > I beg to differ on this one. Having spend several weeks tracking down random processes dying on a > machine that turned out to be a bad sector in the swap partition, I have had great results by > running swap on a RAID-1. If you develop a bad sector in a non-mirrored swap, bad things happen > indeterminately and can be a royal PITA to chase down. It's just a little extra piece of mind. okay .... if the parts of disks is bad that is used for swap, mirroring might help ... but, i wonder, how/why the system used that portion of swap in the first place - even for raid, if sector-10 in swap is bad, why would raid keep trying to write there instead of to sector-1000 ( the systems should be writing data, and read it back to verify ( what it wrote to disk, not the disk cache, is the same as what ( it just read back, before it says, "data is written" and i spent days trackign down a bad memory ... that killed the raid ... - various backups the only reasonable way to make sure [supposedly good] data is not lost where backups does NOT overwrite previous[ly good] backups c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 11:39 ` Alvin Oga @ 2005-01-05 12:02 ` Brad Campbell 2005-01-05 13:23 ` Alvin Oga 0 siblings, 1 reply; 88+ messages in thread From: Brad Campbell @ 2005-01-05 12:02 UTC (permalink / raw) To: Alvin Oga; +Cc: Andy Smith, linux-raid Alvin Oga wrote: > > hi ya brad > > On Wed, 5 Jan 2005, Brad Campbell wrote: > > >>Alvin Oga wrote: >> >>> for swap ... i personally don't see any reason to mirror >>> swap partitions ... >>> - once the system dies, ( power off ), all temp >>> data is useless unless one continues from a coredump >>> ( from the same state as when it went down initially ) >> >>I beg to differ on this one. Having spend several weeks tracking down random processes dying on a >>machine that turned out to be a bad sector in the swap partition, I have had great results by >>running swap on a RAID-1. If you develop a bad sector in a non-mirrored swap, bad things happen >>indeterminately and can be a royal PITA to chase down. It's just a little extra piece of mind. > > > okay .... if the parts of disks is bad that is used for swap, > mirroring might help ... > > but, i wonder, how/why the system used that portion of swap in the first > place > - even for raid, if sector-10 in swap is bad, why would raid keep > trying to write there instead of to sector-1000 Picture lpd gets swapped out on a friday night. Over the weekend it is not used and the drive develops a bad sector in the middle of the file. Monday morning I want to print and the system tries to page lpd back in again. *boom*. I have not looked at the system swap algorithms, but I doubt they include automatic bad block management and read after write verification. I'm making big assumptions here, but I'm assuming they rely on a bad block table created by mkswap and an otherwise clean, functioning swap area. Regards, Brad ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 12:02 ` Brad Campbell @ 2005-01-05 13:23 ` Alvin Oga 2005-01-05 13:33 ` Brad Campbell 2005-01-05 13:36 ` Swap should be mirrored or not? (was Re: ext3 journal on software raid) Andy Smith 0 siblings, 2 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-05 13:23 UTC (permalink / raw) To: Brad Campbell; +Cc: linux-raid On Wed, 5 Jan 2005, Brad Campbell wrote: > Picture lpd gets swapped out on a friday night. Over the weekend it is not used and the drive > develops a bad sector in the middle of the file. Monday morning I want to print and the system tries > to page lpd back in again. *boom*. admin issue ... user related services like printers should NOT be on critical servers and take down what everybody will notice due to unrelated printer problems swap ... swap partitions is by default checked for bad blocks during formatting as swap ... - it is highly unlikely that you'd get a bad sector in swap space - any normal bad things happening to user area of the disks will also happen to swap space - but its unlikely that swap will have bad blocks, while its more likely that users did nto do a badblock check during formatting across the 100GB or 300GB disks ... and even more time twiddling your thumbs on raid'd disks c ya alvin > I have not looked at the system swap algorithms, but I doubt they include automatic bad block > management and read after write verification. I'm making big assumptions here, but I'm assuming they > rely on a bad block table created by mkswap and an otherwise clean, functioning swap area. > > Regards, > Brad > ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 13:23 ` Alvin Oga @ 2005-01-05 13:33 ` Brad Campbell 2005-01-05 14:44 ` parts -- " Alvin Oga 2005-01-05 13:36 ` Swap should be mirrored or not? (was Re: ext3 journal on software raid) Andy Smith 1 sibling, 1 reply; 88+ messages in thread From: Brad Campbell @ 2005-01-05 13:33 UTC (permalink / raw) To: Alvin Oga; +Cc: linux-raid Alvin Oga wrote: > > On Wed, 5 Jan 2005, Brad Campbell wrote: > > >>Picture lpd gets swapped out on a friday night. Over the weekend it is not used and the drive >>develops a bad sector in the middle of the file. Monday morning I want to print and the system tries >>to page lpd back in again. *boom*. > > > admin issue ... user related services like printers should NOT be on > critical servers and take down what everybody will notice due to unrelated > printer problems Ok, perhaps bad example. Pick any service that may get swapped out. Hell.. any bad block in any swap space that develops while that block is in use is going to cause a problem. > swap ... swap partitions is by default checked for bad blocks during > formatting as swap ... > - it is highly unlikely that you'd get a bad sector in swap space Yeah? I have 3 hard disks sitting on my desk that say you are wrong.. > > - any normal bad things happening to user area of the disks will also > happen to swap space I agree. > - but its unlikely that swap will have bad blocks, while its > more likely that users did nto do a badblock check during > formatting across the 100GB or 300GB disks ... and even more > time twiddling your thumbs on raid'd disks I strongly disagree. I have a 250GB drive I just swapped out that was "growing" bad sectors at the rate of 3 per day that did a clean badblocks 5 months ago when it was installed. I refuse to argue this any more. If you want to tell the world that there is no benefit to swap on raid, go ahead. Brad ^ permalink raw reply [flat|nested] 88+ messages in thread
* parts -- Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 13:33 ` Brad Campbell @ 2005-01-05 14:44 ` Alvin Oga 2005-01-19 4:46 ` Clemens Schwaighofer 0 siblings, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-05 14:44 UTC (permalink / raw) To: Brad Campbell; +Cc: linux-raid On Wed, 5 Jan 2005, Brad Campbell wrote: > Ok, perhaps bad example. Pick any service that may get swapped out. Hell.. any bad block in any swap > space that develops while that block is in use is going to cause a problem. yup ... if you have an unstable system .. swapping things in and out of memory and disks will cause you problems > > swap ... swap partitions is by default checked for bad blocks during > > formatting as swap ... > > - it is highly unlikely that you'd get a bad sector in swap space > > Yeah? I have 3 hard disks sitting on my desk that say you are wrong.. that was my whole initial point a few days ago -- get better hardware -- get your hardware from another source -- i do NOT have hardware problems ... - i do NOT buy parts from mthe cheapest place - i do NOT buy parts from people that i had bad parts - i do get an occasional bad part, like the ibm deathstars are infamous - i do get an occasional 1% infant mortality rate ... which is normal - once a server has been up for say 30-60 days ... it stays up for years .... - given the same identical hard disks from different vendors/stores, you will get different failure rates - i use maxtor/quantum, ibm, western digital, seagates, fujitsu ( no one is better than the other disks, other than ( the stupid ibm deathstar problem - how you install it - how you cool it makes all the difference in the world - think about it ... == we all use the same motherboards == we all use the same disks == we all use the same memory == we all use the same linux == whats different ?? ( where you bought yours from and more importantly, ( how you cool things down - i do NOT have problems you guyz are having .... and i've personally use thousnds of disks === get better hardware .. or more to the point ... buy from a computer parts only tier-1 vendor ... not from the millions of me-too online "we are the cheapest mom-n-pop we sell camera's and clothes too webstores" > I have a 250GB drive I just swapped out that was "growing" bad sectors at the rate of 3 per day that > did a clean badblocks 5 months ago when it was installed. you're buying bad hardware from bad vendors c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: parts -- Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 14:44 ` parts -- " Alvin Oga @ 2005-01-19 4:46 ` Clemens Schwaighofer 2005-01-19 5:05 ` Alvin Oga 0 siblings, 1 reply; 88+ messages in thread From: Clemens Schwaighofer @ 2005-01-19 4:46 UTC (permalink / raw) To: Alvin Oga; +Cc: Brad Campbell, linux-raid -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/05/2005 11:44 PM, Alvin Oga wrote: >>I have a 250GB drive I just swapped out that was "growing" bad sectors at the rate of 3 per day that >>did a clean badblocks 5 months ago when it was installed. > > > you're buying bad hardware from bad vendors seriously, thats just wrong. Ever heard of IBM "death"start HDs? Or other stuff? As long as you use IDE hardware you are always close to fail, IDE hardware is done to put much data on cheap disks. If you use IDE stuff in servers, make all raid. And SWAP too, SWAP can be used heavilty, and if there are bad blocks you are hit too. A expensive vendor doesn't help you from crappy HW insealf. - -- [ Clemens Schwaighofer -----=====:::::~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp http://www.tbwajapan.co.jp ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7eYrjBz/yQjBxz8RAnoeAKDs4ZdE+DPktmI8R/yBnFs44MvliQCg5OYy Omq0O6Y5xqWNUFbmHorLyr8= =GTZH -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: parts -- Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-19 4:46 ` Clemens Schwaighofer @ 2005-01-19 5:05 ` Alvin Oga 2005-01-19 5:49 ` Clemens Schwaighofer 0 siblings, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-19 5:05 UTC (permalink / raw) To: Clemens Schwaighofer; +Cc: linux-raid hi ya clemen On Wed, 19 Jan 2005, Clemens Schwaighofer wrote: > On 01/05/2005 11:44 PM, Alvin Oga wrote: > > > you're buying bad hardware from bad vendors > > seriously, thats just wrong. Ever heard of IBM "death"start HDs? Or > other stuff? As long as you use IDE hardware you are always close to > fail, IDE hardware is done to put much data on cheap disks. the "deathstar" ( from thailand to be specific ) disks are the exception and the worst of the bunch majority of all my dead disks are scsi disks .. - the so called better scsi is in fact worst probably because it runs hotter ( spinning faster ) where cooling the case will not help the ball bearings or cooling the disk controller's chips ( scsi: seagate, ibm, fujitsu, .. ( ide: seagate, ibm, fujitsu, wd, maxtor, quantum ... ide disks are warranteed for 1,3 or 5 years and some have a 1,000,000 MTBF ... what you do to it to destroy the mtbf is what makes the difference of how long it will in fact last in your environment and most of my ide disks are approaching 8-10 years and no problems though most of the cpu's or mb have long since been offline for too slow of a cpu -- most all are in offices or 65F server rooms how you build systems does make a difference.. - lots of fans ( at least 2 per ide disk, just in case one dies ) ( that is the same as with scsi .. now you can compare ) > A expensive vendor doesn't help you from crappy HW insealf. lots ... 90% f crappy vendors ... - bad disk or wrong disks - bad mb or wrong mb - bad nic or wrong nic - or no rma number to return bad parts - .. on and on .. - i buy thru tier1 distributors and don't have any "noticeable" bad parts ( maybe .1% failure ( doa )) over 1,000s of ide disks in the past year or two and lasts way past its warranty period == == everybody has their good and bad ideas of what are good disks and not == and does not mean that otehrs should expect the same problem == when everybody buys disks from different vendors and definitely == installed differently ( no redundant fans to cool 7200rpm ide disks ) == operating temp on ide disks should be 25-30C or less per "hddtemp" == c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: parts -- Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-19 5:05 ` Alvin Oga @ 2005-01-19 5:49 ` Clemens Schwaighofer 2005-01-19 7:08 ` Alvin Oga 0 siblings, 1 reply; 88+ messages in thread From: Clemens Schwaighofer @ 2005-01-19 5:49 UTC (permalink / raw) To: Alvin Oga; +Cc: linux-raid -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/19/2005 02:05 PM, Alvin Oga wrote: > hi ya clemen > > On Wed, 19 Jan 2005, Clemens Schwaighofer wrote: > > >>On 01/05/2005 11:44 PM, Alvin Oga wrote: >> >> >>>you're buying bad hardware from bad vendors >> >>seriously, thats just wrong. Ever heard of IBM "death"start HDs? Or >>other stuff? As long as you use IDE hardware you are always close to >>fail, IDE hardware is done to put much data on cheap disks. > > > the "deathstar" ( from thailand to be specific ) disks are the exception > and the worst of the bunch > > majority of all my dead disks are scsi disks .. > - the so called better scsi is in fact worst probably > because it runs hotter ( spinning faster ) > where cooling the case will not help the ball bearings > or cooling the disk controller's chips > > ( scsi: seagate, ibm, fujitsu, .. > ( ide: seagate, ibm, fujitsu, wd, maxtor, quantum ... Since I do SysAdmin as a "get money for it" service I had not a single SCSI disk die (call it luck). But I saw so many dead IDE disks, that I never ever will use IDE stuff in a mission critical or any system that has to run more reliable. I think SCSI disks are built for longer usage, and the thing "faster -> hotter" for SCSI disks is bullshit. IDE disks run also ~7.500 and more. I have a bunch of 15K SCSI disks in use and the rest is 10K SCSI disks, they (10K) run since 3.5 years without a problem. > and most of my ide disks are approaching 8-10 years and no problems > though most of the cpu's or mb have long since been offline for > too slow of a cpu -- most all are in offices or 65F server rooms well thats another imporant thing. Where are those boxes. If you store them in an un-airconditioned room, that is in a building with a central heating, and in a country where you have >2 Months of >30C a day. Then you just call for a server problem. > how you build systems does make a difference.. > - lots of fans ( at least 2 per ide disk, just in case one dies ) > ( that is the same as with scsi .. now you can compare ) well, "I", never build a single Server. I buy them from HP, Supermicro, etc. I am out of the "build all myself" age ... >>A expensive vendor doesn't help you from crappy HW insealf. > > lots ... 90% f crappy vendors ... > - bad disk or wrong disks > - bad mb or wrong mb > - bad nic or wrong nic > - or no rma number to return bad parts > - .. on and on .. > > - i buy thru tier1 distributors and don't have any "noticeable" bad parts > ( maybe .1% failure ( doa )) over 1,000s of ide disks in the past year > or two and lasts way past its warranty period still, you are not save of bad parts, you are perhaps more save to get them replaced with more trustworthy distributors. - -- [ Clemens Schwaighofer -----=====:::::~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp http://www.tbwajapan.co.jp ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7fTLjBz/yQjBxz8RAqyRAJ90VF9uAbmyh4bfJaGho/CN/aTyQgCg4aqK PWGToqzGBLgKHgolF2fqp/Y= =woCo -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: parts -- Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-19 5:49 ` Clemens Schwaighofer @ 2005-01-19 7:08 ` Alvin Oga 0 siblings, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-19 7:08 UTC (permalink / raw) To: Clemens Schwaighofer; +Cc: linux-raid hi ya clemens - yup.. i agree in general except for your "bull shit" comment :-) ( see below ) On Wed, 19 Jan 2005, Clemens Schwaighofer wrote: > Since I do SysAdmin as a "get money for it" service I had not a single > SCSI disk die (call it luck). i think lots of people, probably everybody in here get $$$ for what their doing with the disks they bought and yeah... i'd say you're lucky with the scsi disks you have > But I saw so many dead IDE disks, that I > never ever will use IDE stuff in a mission critical or any system that > has to run more reliable. if its mission critical... i usully have 3 independent synchronized systems doing same "mission critical functions" - "scsi" is not the only answer > I think SCSI disks are built for longer usage, and the thing "faster -> > hotter" for SCSI disks is bullshit. ahh ... i assume you stick your finger on a scsi disks i assume you stick you finger on a ide disks thermodymamics/physics says "most things that go faster will run hotter" and besides .. stick a thermometer and measure it ... no need to bullshit about it - comparing a 15K scsi against an itty-bitty 5400rpm ide is sorta silly and the "comparer" should be shot - comparing a 10K scsi against a 10K ide disk might be noteworthy even if those 10K scsi is year or two older technology, but at 10K rpm.... mechanical problems are the same > well, "I", never build a single Server. I buy them from HP, Supermicro, > etc. I am out of the "build all myself" age ... and you left out the crappy stuff that people tend to buy ... compaqs and dells... which is what i get the calls to come fix for them > still, you are not save of bad parts, you are perhaps more save to get > them replaced with more trustworthy distributors. bingo on "trustworthy distributors" .. that is the 99% of the "right key" since they sell by the millions/billions of those widgets, they wouldnt be carrying it if it was gonna become an rma or warranty problem for them and they probably sell the "same thing" to millions of other customers c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Swap should be mirrored or not? (was Re: ext3 journal on software raid) 2005-01-05 13:23 ` Alvin Oga 2005-01-05 13:33 ` Brad Campbell @ 2005-01-05 13:36 ` Andy Smith 1 sibling, 0 replies; 88+ messages in thread From: Andy Smith @ 2005-01-05 13:36 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 928 bytes --] On Wed, Jan 05, 2005 at 05:23:19AM -0800, Alvin Oga wrote: > On Wed, 5 Jan 2005, Brad Campbell wrote: > > > Picture lpd gets swapped out on a friday night. Over the weekend > > it is not used and the drive develops a bad sector in the middle > > of the file. Monday morning I want to print and the system tries > > to page lpd back in again. *boom*. > > admin issue ... user related services like printers should NOT be on > critical servers and take down what everybody will notice due to unrelated > printer problems The problem is not that an lpd process exists, the problem is that an attempt was made to swap back in a swapped out process while the swap device is screwed. It could happen to any process. Swap is part of your virtual memory, either keep it working or don't use it at all -- you cannot expect your server to keep on working when half its virtual memory is on a device that just died. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 10:56 ` Brad Campbell 2005-01-05 11:39 ` Alvin Oga @ 2005-01-05 14:12 ` Erik Mouw 2005-01-05 14:37 ` Michael Tokarev 2005-01-05 15:17 ` Guy 2 siblings, 1 reply; 88+ messages in thread From: Erik Mouw @ 2005-01-05 14:12 UTC (permalink / raw) To: Brad Campbell; +Cc: Alvin Oga, Andy Smith, linux-raid On Wed, Jan 05, 2005 at 02:56:30PM +0400, Brad Campbell wrote: > I beg to differ on this one. Having spend several weeks tracking down > random processes dying on a machine that turned out to be a bad sector in > the swap partition, I have had great results by running swap on a RAID-1. > If you develop a bad sector in a non-mirrored swap, bad things happen > indeterminately and can be a royal PITA to chase down. It's just a little > extra piece of mind. If you have a bad block in your swap partition and the device doesn't report an error about it, no amount of RAID is going to help you against it. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 14:12 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Erik Mouw @ 2005-01-05 14:37 ` Michael Tokarev 2005-01-05 14:55 ` errors " Alvin Oga 2005-01-05 17:11 ` Erik Mouw 0 siblings, 2 replies; 88+ messages in thread From: Michael Tokarev @ 2005-01-05 14:37 UTC (permalink / raw) To: Erik Mouw; +Cc: Brad Campbell, Alvin Oga, Andy Smith, linux-raid Erik Mouw wrote: > On Wed, Jan 05, 2005 at 02:56:30PM +0400, Brad Campbell wrote: > >>I beg to differ on this one. Having spend several weeks tracking down >>random processes dying on a machine that turned out to be a bad sector in >>the swap partition, I have had great results by running swap on a RAID-1. >>If you develop a bad sector in a non-mirrored swap, bad things happen >>indeterminately and can be a royal PITA to chase down. It's just a little >>extra piece of mind. > > If you have a bad block in your swap partition and the device doesn't > report an error about it, no amount of RAID is going to help you > against it. The drive IS reporting read errors in most cases. But that does not help, really: kernel swapped out some memory but can't read it back, so things are screwed. Just like if you hot-remove a DIMM while the system is running: the kernel loses parts of it's memory, and it can't work anymore. Depending on what was in there ofcourse: the whole system may be screwed, or a single process... The talks isn't about "undetectable" (unreported etc) errors here, but about the fact that the error is here. And if your swap is on raid, in case one component of the array behaves badly, another component will continue to work, so with swap on raid the system will work just fine as if nothing happened in case one of "swap components" (i mean underlying devices) failed for whatever reason. And please, pretty PLEASE stop talking about those mysterious "undetectable" or "unreported" errors here. A drive that develops "unreported" errors just does not work and should not be here in the first place, just like bad memory or CPU: if your cpu or memory is failing, no software tricks helps and the failing part should be replaced BEFORE even thinking about possible ways to recover. /mjt ^ permalink raw reply [flat|nested] 88+ messages in thread
* errors Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 14:37 ` Michael Tokarev @ 2005-01-05 14:55 ` Alvin Oga 2005-01-05 17:11 ` Erik Mouw 1 sibling, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-05 14:55 UTC (permalink / raw) To: Michael Tokarev; +Cc: linux-raid hi ya michael On Wed, 5 Jan 2005, Michael Tokarev wrote: > The drive IS reporting read errors in most cases. and by the time it reports an error ... its too late ... - one has to play detective and figure out why the error occured and prevent it next time - the worst possible thing to do is .. "disk seems to be dying" so 95% of the people say backup the disks .. -- its too too late -- exercising a dead/dying disks will only aggravate the problem even more - luckily, most "disks errors" are silly errors - bad (cheap, not-too-specs) ide cables - 80 conductor vs 40 conductor - combining 2 different ata speed drives on the same idea cable - too long of an ide cable ... 18" is max - disk running too hot ... if its warm to the touch, its too hot ( 35C is maybe okay .. use hddtemp to see what its running at ) - bent disk cables - bad (electrical characteristics) of the ide drivers from the motherboard - ... on and on ... - todays drives are 1000x better quality than 5-10 years ago > so things are screwed. Just like if you hot-remove a DIMM while the > system is running: those that do hot-swap of memory deserve what they get :-) ( i know you're joking ... and i've seen it done by forgetful admins - these atx power supplies are bad for that reason, since the motherboard is still live, even if the pc is off, due to standby voltages floating around > The talks isn't about > "undetectable" (unreported etc) errors here, but about the fact that > the error is here. the trick is to find out what caused the error ... - if you dont figure out what happened ... the problem will continue have fun raiding alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 14:37 ` Michael Tokarev 2005-01-05 14:55 ` errors " Alvin Oga @ 2005-01-05 17:11 ` Erik Mouw 2005-01-06 5:41 ` Brad Campbell 1 sibling, 1 reply; 88+ messages in thread From: Erik Mouw @ 2005-01-05 17:11 UTC (permalink / raw) To: Michael Tokarev; +Cc: Brad Campbell, Alvin Oga, Andy Smith, linux-raid On Wed, Jan 05, 2005 at 05:37:34PM +0300, Michael Tokarev wrote: > Erik Mouw wrote: > >If you have a bad block in your swap partition and the device doesn't > >report an error about it, no amount of RAID is going to help you > >against it. > > The drive IS reporting read errors in most cases. "most cases" and "all cases" makes quite a difference. > And please, pretty PLEASE stop talking about those mysterious > "undetectable" or "unreported" errors here. A drive that develops > "unreported" errors just does not work and should not be here in > the first place, just like bad memory or CPU: if your cpu or memory > is failing, no software tricks helps and the failing part should > be replaced BEFORE even thinking about possible ways to recover. Indeed: any suspicious part should not be used in the recovery process. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:11 ` Erik Mouw @ 2005-01-06 5:41 ` Brad Campbell 0 siblings, 0 replies; 88+ messages in thread From: Brad Campbell @ 2005-01-06 5:41 UTC (permalink / raw) To: Erik Mouw; +Cc: Michael Tokarev, Alvin Oga, Andy Smith, linux-raid Erik Mouw wrote: > On Wed, Jan 05, 2005 at 05:37:34PM +0300, Michael Tokarev wrote: > >>Erik Mouw wrote: >> >>>If you have a bad block in your swap partition and the device doesn't >>>report an error about it, no amount of RAID is going to help you >>>against it. >> >>The drive IS reporting read errors in most cases. > > > "most cases" and "all cases" makes quite a difference. > Actually it *was* reporting *all* read errors. It was an early Maxtor 1GB drive and these have been notoriuosly bad for being problematic *however* they have been frightfully good at accurately reporting exactly what was wrong. In this case I was pretty new to the Linux sysadmin thing and never actually really noticed the disk errors in the syslog and correlated them to the process dying. (it was a fair few years ago now). I actually have never had an ATA disk develop errors it did not report. My point remains the same. By putting your swap on a RAID (of any redundant variety) you are increasing the chances of machine survival against disk errors, be they single bit, bad block or dead drive. Talking of Maxtor drives. I have a unit here with less than 6000 hours on it that has started growing bad sectors at an alarming rate. All accurately reported by SMART mind you (clever little disk), but after running a badblocks -n on it (to really shake them loose) the reallocated sector count has halved! Now how can a drive un-reallocate dud sectors? Brad ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 10:56 ` Brad Campbell 2005-01-05 11:39 ` Alvin Oga 2005-01-05 14:12 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Erik Mouw @ 2005-01-05 15:17 ` Guy 2005-01-05 15:33 ` Alvin Oga 2005-01-05 15:48 ` Peter T. Breuer 2 siblings, 2 replies; 88+ messages in thread From: Guy @ 2005-01-05 15:17 UTC (permalink / raw) To: 'Brad Campbell', 'Alvin Oga' Cc: 'Andy Smith', linux-raid I agree, but for a different reason. Your reason is new to me. I don't want a down system due to a single disk failure. Loosing the swap disk would kill the system. Maybe this is Peter's cause of frequent corruption? I mirror everything, or RAID5. Normally, no downtime due to disk failures. Guy -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Brad Campbell Sent: Wednesday, January 05, 2005 5:57 AM To: Alvin Oga Cc: Andy Smith; linux-raid@vger.kernel.org Subject: Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Alvin Oga wrote: > > for swap ... i personally don't see any reason to mirror > swap partitions ... > - once the system dies, ( power off ), all temp > data is useless unless one continues from a coredump > ( from the same state as when it went down initially ) I beg to differ on this one. Having spend several weeks tracking down random processes dying on a machine that turned out to be a bad sector in the swap partition, I have had great results by running swap on a RAID-1. If you develop a bad sector in a non-mirrored swap, bad things happen indeterminately and can be a royal PITA to chase down. It's just a little extra piece of mind. Regards, Brad - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 15:17 ` Guy @ 2005-01-05 15:33 ` Alvin Oga 2005-01-05 16:22 ` Michael Tokarev ` (2 more replies) 2005-01-05 15:48 ` Peter T. Breuer 1 sibling, 3 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-05 15:33 UTC (permalink / raw) To: Guy; +Cc: linux-raid On Wed, 5 Jan 2005, Guy wrote: > I agree, but for a different reason. Your reason is new to me. .. > Loosing the swap disk would kill the system. if one is using swap space ... i'd add more memory .. before i'd use raid - swap is too slow and as you folks point out, it could die due to (unlikely) bad disk sectors in swap area > I don't want a down system due to a single disk failure. that's what raid's for :-) > I mirror everything, or RAID5. Normally, no downtime due to disk failures. the problem with mirror ( raid1 ).. or raid5 ... - if you have a bad diska ... all "bad data" will/could also get copied to the good disk - "bad data" is hard to figure out in code ... to prevent it from getting copied ... how does it know with 100% certainty - if you know why it's bad data, it's lot easier to know which data is more correct than the bad one - as everybody has pointed out .. bad data ( disk errors ) can occur for any number of gazillion reasons have fun raiding alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 15:33 ` Alvin Oga @ 2005-01-05 16:22 ` Michael Tokarev 2005-01-05 17:23 ` Peter T. Breuer 2005-01-05 16:23 ` Andy Smith 2005-01-05 17:07 ` Guy 2 siblings, 1 reply; 88+ messages in thread From: Michael Tokarev @ 2005-01-05 16:22 UTC (permalink / raw) To: linux-raid Alvin Oga wrote: > On Wed, 5 Jan 2005, Guy wrote: > >>I agree, but for a different reason. Your reason is new to me. > ... >>Loosing the swap disk would kill the system. > > if one is using swap space ... i'd add more memory .. before i'd use raid > - swap is too slow and as you folks point out, it could die > due to (unlikely) bad disk sectors in swap area It isn't always practical. You add as much memory as needed for your "typical workload". But there may be "spikes" of load with that you have to deal somehow. Adding more memory to cover that "spikes" may be too expensive. Also, if your "typical workload" requires eg 2Gb memory, adding another, say, 2Gb to cover "spikes" means you have to reconfigure the kernel to support large amount of memory, which also costs something in terms of speed on i386 architecture. Disks are *much* cheaper than ram in terms of money/Mb. >>I don't want a down system due to a single disk failure. > > that's what raid's for :-) > >>I mirror everything, or RAID5. Normally, no downtime due to disk failures. > > the problem with mirror ( raid1 ).. or raid5 ... > - if you have a bad diska ... all "bad data" will/could also get > copied to the good disk Again: pretty PLEASE, stop talking about thouse mysterious "silent corruption/errors". Errors gets detected. It is *very* unlikely case when an error on disk (either unability to read, or reading the "wrong" (aka not the same as has been written) data) will not be detected during read, and if you do care about that cases, you have to use some very different hardware with every component (CPU, memory, buses, controllers etc etc) at least tripled, with hardware-level online monitoring/comparing stuff to detect errors at any level and to switch to another component if one is "lying". > - "bad data" is hard to figure out in code ... to prevent it from > getting copied ... how does it know with 100% certainty Nothing is 100% certain.. maybe except that we all will die sometime... > - if you know why it's bad data, it's lot easier to know which > data is more correct than the bad one Nothing is "more correct". If the disk isn't working somehow, we know this (as it reports errors) and kick it from the array. If disk "does not work silently", see above. /mjt ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 16:22 ` Michael Tokarev @ 2005-01-05 17:23 ` Peter T. Breuer 0 siblings, 0 replies; 88+ messages in thread From: Peter T. Breuer @ 2005-01-05 17:23 UTC (permalink / raw) To: linux-raid Michael Tokarev <mjt@tls.msk.ru> wrote: > Again: pretty PLEASE, stop talking about thouse mysterious "silent > corruption/errors". Errors gets detected. You confuse them here with failures (which probably get detected, but then who can say!). An error occurs when you do a sum on paper and you forget to carry one in the third column. In colloquial terms, it's a "mistake". Life carries on. A failure occurs when your brain explodes and CNN comes round and interviews your next door neignbour about the hole in their wall. > It is *very* unlikely > case when an error on disk (either unability to read, or reading > the "wrong" (aka not the same as has been written) data) will not > be detected during read. It's practically certain that it won't be "detected", because it is on disk as far as anyone and anything can tell - there would have been a failure if that were not the case. It's an ordinary datum. > , and if you do care about that cases, you > have to use some very different hardware with every component > (CPU, memory, buses, controllers etc etc) at least tripled, with > hardware-level online monitoring/comparing stuff to detect errors No, that detects errors internally (and corrects them, or else it produces "failures" that are externally visible in place of them, or else it doesn't detect them and the errors are also externally visible). > at any level and to switch to another component if one is "lying". It still leaves the errors. I don't know why everyone has such semantic problems with this! Think of an error as a "bug". You catch those bugs you can see, and don't catch the bugs you can't see. There are always bugs you can't see (hey!, if you saw them you would correct them, right? Or at least die die die). It is simply a classification. Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 15:33 ` Alvin Oga 2005-01-05 16:22 ` Michael Tokarev @ 2005-01-05 16:23 ` Andy Smith 2005-01-05 16:30 ` Andy Smith 2005-01-05 17:04 ` swp - " Alvin Oga 2005-01-05 17:07 ` Guy 2 siblings, 2 replies; 88+ messages in thread From: Andy Smith @ 2005-01-05 16:23 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 1084 bytes --] On Wed, Jan 05, 2005 at 07:33:55AM -0800, Alvin Oga wrote: > On Wed, 5 Jan 2005, Guy wrote: > > > I agree, but for a different reason. Your reason is new to me. > .. > > Loosing the swap disk would kill the system. > > if one is using swap space ... i'd add more memory .. before i'd use raid > - swap is too slow and as you folks point out, it could die > due to (unlikely) bad disk sectors in swap area This again is besides the point. As I said already swap is part of your virtual memory and if you can't keep it available you should not be using it. It is the same as saying that your machine will die if half its RAM suddenly ceased to exist while it was running. Your recommendations so far have been "don't run processes which might swap" and "don't let swap be used". If you yourself are able to keep to both of these 100% of the time may I ask why you yourself have any swap at all? ometimes) or those of us in the real world where swap is desirable and may (sometimes) be used, a swap device failure *will* *take* *the* *machine* *down*. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 16:23 ` Andy Smith @ 2005-01-05 16:30 ` Andy Smith 2005-01-05 17:04 ` swp - " Alvin Oga 1 sibling, 0 replies; 88+ messages in thread From: Andy Smith @ 2005-01-05 16:30 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 453 bytes --] On Wed, Jan 05, 2005 at 04:23:37PM +0000, Andy Smith wrote: > ometimes) or those of us in the real world where swap is desirable > and may (sometimes) be used, a swap device failure *will* *take* > *the* *machine* *down*. Something strange happened with vim there. That was meant to read: "For those of us in the real world where swap is (sometimes) desirable and may (sometimes) be used, a swap device failure *will* *take* *the* *machine* *down*." [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 16:23 ` Andy Smith 2005-01-05 16:30 ` Andy Smith @ 2005-01-05 17:04 ` Alvin Oga 2005-01-05 17:26 ` Andy Smith 1 sibling, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-05 17:04 UTC (permalink / raw) To: Andy Smith; +Cc: linux-raid On Wed, 5 Jan 2005, Andy Smith wrote: > On Wed, Jan 05, 2005 at 07:33:55AM -0800, Alvin Oga wrote: > > > > if one is using swap space ... i'd add more memory .. before i'd use raid > > - swap is too slow and as you folks point out, it could die > > due to (unlikely) bad disk sectors in swap area ... > Your recommendations that'd be your comment ... that is not whati said above and all i said, was use memory before you use swap on disks and if you are at the 2GB lmit of your mb ... you obviously don't have a choice - if you are using 128MB of memory and using 2GB of swap and bitching about a slow box or system crashing due to swap... - that was the point ... add more memory - and i don't think anybody is idiotic enough to add more memory for the "spikes" in the workload > so far have been "don't run processes which > might swap" and "don't let swap be used". If you yourself are able > to keep to both of these 100% of the time may I ask why you yourself > have any swap at all? you're twisting things again... but no problem.. have fun doing that > ometimes) or those of us in the real world where swap is desirable > and may (sometimes) be used, a swap device failure *will* *take* > *the* *machine* *down*. my real world is obviously better .... since we do NOT suffer from these mysterious disks crashes we go to fix peoples problems c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:04 ` swp - " Alvin Oga @ 2005-01-05 17:26 ` Andy Smith 2005-01-05 18:32 ` Alvin Oga 0 siblings, 1 reply; 88+ messages in thread From: Andy Smith @ 2005-01-05 17:26 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 3177 bytes --] On Wed, Jan 05, 2005 at 09:04:57AM -0800, Alvin Oga wrote: > On Wed, 5 Jan 2005, Andy Smith wrote: > > > On Wed, Jan 05, 2005 at 07:33:55AM -0800, Alvin Oga wrote: > > > > > > if one is using swap space ... i'd add more memory .. before i'd use raid > > > - swap is too slow and as you folks point out, it could die > > > due to (unlikely) bad disk sectors in swap area > ... > > > Your recommendations > > that'd be your comment ... that is not whati said above Direct quote: i'd add more memory before i'd use raid > and all i said, was use memory before you use swap on disks Which means what? Who is there on this list who likes to use swap *before* physical memory? Do all your machines which you believe have adequate memory also have no swap configured? Fact is if your machine has swap configured then that swap is part of your virtual memory and if a device that is providing part of your virtual memory suddenly fails then your machine is going down. > and if you are at the 2GB lmit of your mb ... you obviously don't > have a choice > - if you are using 128MB of memory and using 2GB of swap > and bitching about a slow box or system crashing due to swap... > - that was the point ... add more memory No one here is bitching about a slow machine due to swap usage and if they were I'd wonder why they are doing it on linux-raid. I repeat, if "add more memory" is your answer to "swapping on a single device which then dies kills my machine" then does that mean that your machines are configured with no swap? All people are saying is that if you don't mirror swap then disk failures cause downtime. You are replying to add more memory and don'trun things that can get swapped. Those don't seem like very useful recommendations. > - and i don't think anybody is idiotic enough to add > more memory for the "spikes" in the workload OK so you must add swap to handle those spikes which means either you are happy that your machine will crash should the device that the swap is on die, or you use swap on a mirror to try to mitigate that. > > so far have been "don't run processes which > > might swap" and "don't let swap be used". If you yourself are able > > to keep to both of these 100% of the time may I ask why you yourself > > have any swap at all? > > you're twisting things again... but no problem.. have fun doing that From previous email (not a direct quote): Don't run lpd on user-accessible machine (after given an example of some lpd process which gets swapped out and back in again). > > ometimes) or those of us in the real world where swap is desirable > > and may (sometimes) be used, a swap device failure *will* *take* > > *the* *machine* *down*. > > my real world is obviously better .... since we do NOT suffer > from these mysterious disks crashes If you do not suffer disk crashes then why do you use mirrors at all? If you do suffer disk crashes then any disk that is providing swap may very well cause the machine to crash. I thought everyone suffered disk crashes and that was the point of RAID. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:26 ` Andy Smith @ 2005-01-05 18:32 ` Alvin Oga 2005-01-05 22:35 ` Andy Smith 0 siblings, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-05 18:32 UTC (permalink / raw) To: Andy Smith; +Cc: linux-raid hi ya andy On Wed, 5 Jan 2005, Andy Smith wrote: > > > Your recommendations > > > > that'd be your comment ... that is not whati said above > > Direct quote: > > i'd add more memory before i'd use raid i see ... when i say "i would use" ... i dont mean or imply others to do so .. if i do mean "you" should, or i strongly recommend ... i usually explicitly say so > > and all i said, was use memory before you use swap on disks > > Which means what? Who is there on this list who likes to use swap > *before* physical memory? you'd be surprized how many people wonder why their system is slow and they using 100% swap ( hundreds of MB of swap ) and little memory beause its $50 of expensive memory > Do all your machines which you believe have adequate memory also > have no swap configured? yes .... in my machines .. they are all mostly tuned for specfic tasks ... very little ( say 0.05% swap usage even at peak ) > Fact is if your machine has swap configured then that swap is part > of your virtual memory and if a device that is providing part of > your virtual memory suddenly fails then your machine is going down. yup... and in some systems ... having swap ( too slow ) is NOT an option ... ( embedded systems, realtime operations, ... ) > I repeat, if "add more memory" is your answer to "swapping on a > single device which then dies kills my machine" then does that mean > that your machines are configured with no swap? i'm NOT the one having hardware problems of any sort ... i'm stating people that are having problems usually have problems because of many possible reasons ... - most common one is, that it's a machine just slapped together with parts on sales from far away website vendors - if the machine cannot handle swapp ... to one partiton or or swap on other disks, than they have a serious hardware problem that they bought pieces of hw junk vs buying good parts from known good vendors == == you should NEVER have swap problems == otherwise, toss that system out or salvage what you can == > All people are saying is that if you don't mirror swap then disk > failures cause downtime. yes ... and i'm just saying, if you dont know why swapp failed or that if downtime is important, use better quality hardware and install it properly ... maintain it properly ... if you forget about it .. the disk ... the disk will get lonely too will forget about holding its 1's and 0's too > You are replying to add more memory and > don'trun things that can get swapped. you're twisting things gain > Those don't seem like very useful recommendations. that is becuase you're twisting things so you can make comments i didnt say > > - and i don't think anybody is idiotic enough to add > > more memory for the "spikes" in the workload > > OK so you must add swap to handle those spikes which means either > you are happy that your machine will crash should the device that > the swap is on die, or you use swap on a mirror to try to mitigate > that. this is pointless isnt it ... are you an idiot or what .. do you like to put words and recommendations that i didnt say and twist it in your favor > > From previous email (not a direct quote): > > Don't run lpd on user-accessible machine you obviously do NOT understand where to run lpd and where to run dns and where to run pop and where to run ssh and where to run mta ... and on and on and on ... > If you do not suffer disk crashes then why do you use mirrors at > all? i do NOT use mirrors for the protection against disk failures nobody said i did .. you again are twisting things into your own ideas and misconceptions > If you do suffer disk crashes then any disk that is providing > swap may very well cause the machine to crash. i dont have that problem ... but if someone ddid have that problem ... i assuem they are smart enough to figure out within 5-10 minutes why the disk/system is crashing > I thought everyone suffered disk crashes and that was the point of > RAID. not everybody suffers disk crashes ... in such great numbers that raid is better solution ... - raid is NOT theonly solution == ever hear of high availability ... = clusters ... = even plain ole backups there are more than one solution to one disk crashing c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 18:32 ` Alvin Oga @ 2005-01-05 22:35 ` Andy Smith 2005-01-06 0:57 ` Guy 0 siblings, 1 reply; 88+ messages in thread From: Andy Smith @ 2005-01-05 22:35 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 7865 bytes --] On Wed, Jan 05, 2005 at 10:32:37AM -0800, Alvin Oga wrote: > > hi ya andy > > On Wed, 5 Jan 2005, Andy Smith wrote: > > > > > Your recommendations > > > > > > that'd be your comment ... that is not whati said above > > > > Direct quote: > > > > i'd add more memory before i'd use raid > > i see ... when i say "i would use" ... i dont mean or imply > others to do so .. That is not a very useful thing to say in response to someone who suggests using RAID mirrors for swap. > > > and all i said, was use memory before you use swap on disks > > > > Which means what? Who is there on this list who likes to use swap > > *before* physical memory? > > you'd be surprized how many people wonder why their system is slow > and they using 100% swap ( hundreds of MB of swap ) and little memory > beause its $50 of expensive memory What you said was (and I quoted it for you) "use memory before you use swap". I am asking you if this also is a useful thing to say, because I was not aware there was anyone who would prefer to use swap before memory. Unless you simply mean "add more memory" which again would be a strange thing to say in a discussion about putting swap on a RAID mirror -> implies "always have enough RAM, configure no swap" but since you seem to have a great objection to me trying to make sense of what you're saying I won't go any further stating what I think you imply. > > Do all your machines which you believe have adequate memory also > > have no swap configured? > > yes .... in my machines .. they are all mostly tuned for specfic > tasks ... very little ( say 0.05% swap usage even at peak ) So "no" then as I asked if your machines had any swap configured and you reply that they use 0.05% at peak. To use 0.05% they need to have swap configured. So your machines do have swap configured, that is what the question was. > > Fact is if your machine has swap configured then that swap is part > > of your virtual memory and if a device that is providing part of > > your virtual memory suddenly fails then your machine is going down. > > yup... > > and in some systems ... having swap ( too slow ) is NOT an option ... > ( embedded systems, realtime operations, ... ) That's great but it's irrelevant to this discussion since the situation discussed is swap on mirror or not. Whether swap is required or beneficial is an admin issue outside the scope of RAID. We can assume that the admin ahs already determined that configuring some amount of swap is required, otherwise we cannot assume anything about their setup and will be telling them how to lay out their filesystems, what distribution to use, etc. etc.. There are some things that just don't need to be said and on a RAID list, "add more memory, swap is slow" is IMHO one of them. > == you should NEVER have swap problems > == otherwise, toss that system out or salvage what you can > == If you use RAID-1 (-4, -5,- 10, etc.) then I think you are acknowledging that your disks are a cause for concern for you. Otherwise no one would be using RAID. If you would not be willing to say the following: you should NEVER have filesystem problems otherwise, toss that system out or salvage what you can then I don't understand why you are willing to say it when it comes to swap and not a filesystem. Disks fail, it's why we're here on this list. > > You are replying to add more memory and > > don'trun things that can get swapped. > > you're twisting things gain All I've got to work with is what you're giving me. Direct quotes of yours lead me to believe that these are your points. In a discussion about swap on RAID you have clearly stated to add more RAM, use higher quality components, not run certain userland processes. If you say these things in a discussion about swap on RAID then I'm left to believe either that you see these things as an alternative to swap on RAID or else you are just posting irrelevant basic admin tips that have nothing to do with linux RAID. > > Those don't seem like very useful recommendations. > > that is becuase you're twisting things so you can make > comments i didnt say Then please explain yourself better using points that are relevant to RAID using md on Linux. > > > - and i don't think anybody is idiotic enough to add > > > more memory for the "spikes" in the workload > > > > OK so you must add swap to handle those spikes which means either > > you are happy that your machine will crash should the device that > > the swap is on die, or you use swap on a mirror to try to mitigate > > that. > > this is pointless isnt it ... > > are you an idiot or what .. It's possible to disagree and debate while still being civil. If you don't have that skill then I'm not willing to spend time teaching you it. > do you like to put words and recommendations that i didnt say > and twist it in your favor No, I like understanding your point but at the moment all I can see is basic unix admin recommendations that are unrelated to the discussion at hand - you admit you have swap configured on your servers so all the other stuff you have mentioned is irrelevant. So help me understand. I don't understand how you intend to survive a disk failure involving your swap unless you put it on a mirror or configure no swap or never have a disk failure, ever, or intend to have downtime when you do have a disk failure. So help me understand. > > From previous email (not a direct quote): > > > > Don't run lpd on user-accessible machine > > you obviously do NOT understand where to run lpd and where > to run dns and where to run pop and where to run ssh and where > to run mta ... and on and on and on ... You have no idea whether I do or do not know these things and on this list you never will, because placement of these things is irrelevant to linux raid. > > If you do not suffer disk crashes then why do you use mirrors at > > all? > > i do NOT use mirrors for the protection against disk failures > > nobody said i did .. you again are twisting things into your > own ideas and misconceptions Well indeed, if you never suffer disk failures as you go on to say then I imagine you don't use mirrors for that.. > > If you do suffer disk crashes then any disk that is providing > > swap may very well cause the machine to crash. > > i dont have that problem ... but if someone ddid have that > problem ... i assuem they are smart enough to figure out > within 5-10 minutes why the disk/system is crashing Such a person, if they were not as fortunate and/or skiled at purchasing hardware as you appear to be, and so happened to suffer the occasional disk failure, may wish that their system did not crash and suffer 5 to 10 minutes of downtime because a disk failed. They may wish that the device would just fail and they could schedule a downtime or hot swap it. If you are not one of those people (and, since you say you don't have disk failures then you wouldn't be), it doesn't mean those people don't exist and don't have a valid requirement. > > I thought everyone suffered disk crashes and that was the point of > > RAID. > > not everybody suffers disk crashes ... in such great numbers > that raid is better solution ... > - raid is NOT theonly solution > > == ever hear of high availability ... > = clusters ... > = even plain ole backups > > there are more than one solution to one disk crashing Is there any reason why someone could not use swap on raid as well as any of the above as they see fit? Maybe those who advocate swap on raid already use high availablity and clusters. And we'd certainly hope they have backups. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 22:35 ` Andy Smith @ 2005-01-06 0:57 ` Guy 2005-01-06 1:28 ` Mike Hardy 2005-01-06 5:01 ` Alvin Oga 0 siblings, 2 replies; 88+ messages in thread From: Guy @ 2005-01-06 0:57 UTC (permalink / raw) To: 'Andy Smith', linux-raid Going off topic, but... I come from an HP-UX environment. With HP-UX, I have always had to configure swap space. Maybe only for 1 reason. If you used shared memory, you must have an equal amount of swap space available. We always used shared memory (shmget). It was called a "backing store", if I recall. Including Informix, we used almost the hardware (OS) limit of about 1.7 Gig of shared memory on some systems. So we needed at least 1.7 Gig of swap space. We would allocate 3-4 Gig I think, just to be safe. The swap space would be allocated (reserved), but not used, unless you really ran low on RAM. So, the question is: Assume I have enough RAM to never need to swap. Do I need any swap space with Linux? Silly story: I once had a 486 with 4 Meg of ram. Running Windows 3.1 I think. I had 8 Meg of swap space. So 12 meg total available virtual memory. One day I added 16 Meg of RAM. So now I had 20 Meg of RAM. I deleted my swap space. Everyone told me I needed 20-40 Meg of swap space now! Swap space should be 2 time RAM size. How crazy, my memory requirements did not change, just the amount of memory. I used that system for a year or so like that. Go figure! Guy -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Andy Smith Sent: Wednesday, January 05, 2005 5:36 PM To: linux-raid@vger.kernel.org Subject: Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) On Wed, Jan 05, 2005 at 10:32:37AM -0800, Alvin Oga wrote: > > hi ya andy > > On Wed, 5 Jan 2005, Andy Smith wrote: > > > > > Your recommendations > > > > > > that'd be your comment ... that is not whati said above > > > > Direct quote: > > > > i'd add more memory before i'd use raid > > i see ... when i say "i would use" ... i dont mean or imply > others to do so .. That is not a very useful thing to say in response to someone who suggests using RAID mirrors for swap. > > > and all i said, was use memory before you use swap on disks > > > > Which means what? Who is there on this list who likes to use swap > > *before* physical memory? > > you'd be surprized how many people wonder why their system is slow > and they using 100% swap ( hundreds of MB of swap ) and little memory > beause its $50 of expensive memory What you said was (and I quoted it for you) "use memory before you use swap". I am asking you if this also is a useful thing to say, because I was not aware there was anyone who would prefer to use swap before memory. Unless you simply mean "add more memory" which again would be a strange thing to say in a discussion about putting swap on a RAID mirror -> implies "always have enough RAM, configure no swap" but since you seem to have a great objection to me trying to make sense of what you're saying I won't go any further stating what I think you imply. > > Do all your machines which you believe have adequate memory also > > have no swap configured? > > yes .... in my machines .. they are all mostly tuned for specfic > tasks ... very little ( say 0.05% swap usage even at peak ) So "no" then as I asked if your machines had any swap configured and you reply that they use 0.05% at peak. To use 0.05% they need to have swap configured. So your machines do have swap configured, that is what the question was. > > Fact is if your machine has swap configured then that swap is part > > of your virtual memory and if a device that is providing part of > > your virtual memory suddenly fails then your machine is going down. > > yup... > > and in some systems ... having swap ( too slow ) is NOT an option ... > ( embedded systems, realtime operations, ... ) That's great but it's irrelevant to this discussion since the situation discussed is swap on mirror or not. Whether swap is required or beneficial is an admin issue outside the scope of RAID. We can assume that the admin ahs already determined that configuring some amount of swap is required, otherwise we cannot assume anything about their setup and will be telling them how to lay out their filesystems, what distribution to use, etc. etc.. There are some things that just don't need to be said and on a RAID list, "add more memory, swap is slow" is IMHO one of them. > == you should NEVER have swap problems > == otherwise, toss that system out or salvage what you can > == If you use RAID-1 (-4, -5,- 10, etc.) then I think you are acknowledging that your disks are a cause for concern for you. Otherwise no one would be using RAID. If you would not be willing to say the following: you should NEVER have filesystem problems otherwise, toss that system out or salvage what you can then I don't understand why you are willing to say it when it comes to swap and not a filesystem. Disks fail, it's why we're here on this list. > > You are replying to add more memory and > > don'trun things that can get swapped. > > you're twisting things gain All I've got to work with is what you're giving me. Direct quotes of yours lead me to believe that these are your points. In a discussion about swap on RAID you have clearly stated to add more RAM, use higher quality components, not run certain userland processes. If you say these things in a discussion about swap on RAID then I'm left to believe either that you see these things as an alternative to swap on RAID or else you are just posting irrelevant basic admin tips that have nothing to do with linux RAID. > > Those don't seem like very useful recommendations. > > that is becuase you're twisting things so you can make > comments i didnt say Then please explain yourself better using points that are relevant to RAID using md on Linux. > > > - and i don't think anybody is idiotic enough to add > > > more memory for the "spikes" in the workload > > > > OK so you must add swap to handle those spikes which means either > > you are happy that your machine will crash should the device that > > the swap is on die, or you use swap on a mirror to try to mitigate > > that. > > this is pointless isnt it ... > > are you an idiot or what .. It's possible to disagree and debate while still being civil. If you don't have that skill then I'm not willing to spend time teaching you it. > do you like to put words and recommendations that i didnt say > and twist it in your favor No, I like understanding your point but at the moment all I can see is basic unix admin recommendations that are unrelated to the discussion at hand - you admit you have swap configured on your servers so all the other stuff you have mentioned is irrelevant. So help me understand. I don't understand how you intend to survive a disk failure involving your swap unless you put it on a mirror or configure no swap or never have a disk failure, ever, or intend to have downtime when you do have a disk failure. So help me understand. > > From previous email (not a direct quote): > > > > Don't run lpd on user-accessible machine > > you obviously do NOT understand where to run lpd and where > to run dns and where to run pop and where to run ssh and where > to run mta ... and on and on and on ... You have no idea whether I do or do not know these things and on this list you never will, because placement of these things is irrelevant to linux raid. > > If you do not suffer disk crashes then why do you use mirrors at > > all? > > i do NOT use mirrors for the protection against disk failures > > nobody said i did .. you again are twisting things into your > own ideas and misconceptions Well indeed, if you never suffer disk failures as you go on to say then I imagine you don't use mirrors for that.. > > If you do suffer disk crashes then any disk that is providing > > swap may very well cause the machine to crash. > > i dont have that problem ... but if someone ddid have that > problem ... i assuem they are smart enough to figure out > within 5-10 minutes why the disk/system is crashing Such a person, if they were not as fortunate and/or skiled at purchasing hardware as you appear to be, and so happened to suffer the occasional disk failure, may wish that their system did not crash and suffer 5 to 10 minutes of downtime because a disk failed. They may wish that the device would just fail and they could schedule a downtime or hot swap it. If you are not one of those people (and, since you say you don't have disk failures then you wouldn't be), it doesn't mean those people don't exist and don't have a valid requirement. > > I thought everyone suffered disk crashes and that was the point of > > RAID. > > not everybody suffers disk crashes ... in such great numbers > that raid is better solution ... > - raid is NOT theonly solution > > == ever hear of high availability ... > = clusters ... > = even plain ole backups > > there are more than one solution to one disk crashing Is there any reason why someone could not use swap on raid as well as any of the above as they see fit? Maybe those who advocate swap on raid already use high availablity and clusters. And we'd certainly hope they have backups. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 0:57 ` Guy @ 2005-01-06 1:28 ` Mike Hardy 2005-01-06 3:32 ` Guy 2005-01-06 5:04 ` Alvin Oga 2005-01-06 5:01 ` Alvin Oga 1 sibling, 2 replies; 88+ messages in thread From: Mike Hardy @ 2005-01-06 1:28 UTC (permalink / raw) To: linux-raid Guy wrote: > So, the question is: > Assume I have enough RAM to never need to swap. > Do I need any swap space with Linux? This has been hashed out at great length on linux-kernel - with a few entrenched positions emerging, if I recall correctly. There are those that think if they size the machine correctly, they shouldn't need swap, and they're right. > I had 8 Meg of swap space. So 12 meg total available virtual memory. > One day I added 16 Meg of RAM. So now I had 20 Meg of RAM. I deleted my > swap space. Everyone told me I needed 20-40 Meg of swap space now! Swap > space should be 2 time RAM size. How crazy, my memory requirements did not > change, just the amount of memory. I used that system for a year or so like > that. Go figure! This story pretty much sums up that position, and I've certainly been in that position myself. There are others (notably the maintainer of part of that code - Andrea Arcangeli if I recall correctly, though I apologize if that's a misattribution) who believe you should always have swap because it will allow your system to have higher throughput. If you process a large I/O, for instance, the kernel can swap out live processes to devote more RAM to VFS caching. That hurts latency though, and the nightly slocate run is a pathlogical example of this. You wake up in the morning and your machine is crawling while it swaps everything back in. There's a "swappiness" knob you can twiddle in /proc or /sys to alter this, but the general idea is that you can improve throughput on a machine by having swap even if there is enough ram for all processes I've got machines with and without swap, but I typically run all servers with swap to handle ram-usage spikes I'm not expecting (you never know) while I run my laptop without swap when possible to avoid latency issues with swappiness. As with all things, its policy decisions and tradeoffs :-) -Mike ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 1:28 ` Mike Hardy @ 2005-01-06 3:32 ` Guy 2005-01-06 4:49 ` Mike Hardy 2005-01-06 5:04 ` Alvin Oga 1 sibling, 1 reply; 88+ messages in thread From: Guy @ 2005-01-06 3:32 UTC (permalink / raw) To: 'Mike Hardy', linux-raid Ok, good answer. Thanks. I understand the "spikes" issue. I really do plan to have swap space all the time, but good to know it is optional if you have enough RAM. Maybe the concept of swapping is becoming obsolete? In the past, some systems had hardware limits. Like 64K, 640K, 16M, 64M. You had no choice but to swap stuff out. Or use overlays. I have worked on systems where the app had to swap chunks of memory to disk and back. There was no OS support for virtual memory. We had fixed head disks to give better performance. I even recall hardware that could bank switch sections of memory to break the 640K limit! Even IBM mainframes had a 256Meg limit, but could go beyond that by bank switching. But now hardware has caught up to programmers. Most systems can support more RAM than most programs need. With PC based systems (and some others I assume), 1 Gig of RAM is very cheap! But I did note someone said you had to do something to break the 2Gig boundary in Linux with x68 based systems. That's too bad. In a few years, most people will be in the 64 bit world I guess. I hope that corrects the 2Gig boundary. The next boundary (8,589,934,592 Gig) should be well beyond anything we would ever need, well, for at least a few more years! :) But then we could go un-signed and double that! Of course, disks will be even bigger! I can't wait! Of course you can't put 8,589,934,592 Gig of RAM in a 64 bit computer today. If you consider Moore's Law and RAM. "transistors on integrated circuits tend to double every 18 to 24 months" Assuming we are at a about 36 bits today (I think 64 Gig is about as much as is reasonable today). We should reach the 64 bit limit in 42-56 years. Maybe it will be a long wait? :) Guy -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Mike Hardy Sent: Wednesday, January 05, 2005 8:28 PM To: linux-raid@vger.kernel.org Subject: Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Guy wrote: > So, the question is: > Assume I have enough RAM to never need to swap. > Do I need any swap space with Linux? This has been hashed out at great length on linux-kernel - with a few entrenched positions emerging, if I recall correctly. There are those that think if they size the machine correctly, they shouldn't need swap, and they're right. > I had 8 Meg of swap space. So 12 meg total available virtual memory. > One day I added 16 Meg of RAM. So now I had 20 Meg of RAM. I deleted my > swap space. Everyone told me I needed 20-40 Meg of swap space now! Swap > space should be 2 time RAM size. How crazy, my memory requirements did not > change, just the amount of memory. I used that system for a year or so like > that. Go figure! This story pretty much sums up that position, and I've certainly been in that position myself. There are others (notably the maintainer of part of that code - Andrea Arcangeli if I recall correctly, though I apologize if that's a misattribution) who believe you should always have swap because it will allow your system to have higher throughput. If you process a large I/O, for instance, the kernel can swap out live processes to devote more RAM to VFS caching. That hurts latency though, and the nightly slocate run is a pathlogical example of this. You wake up in the morning and your machine is crawling while it swaps everything back in. There's a "swappiness" knob you can twiddle in /proc or /sys to alter this, but the general idea is that you can improve throughput on a machine by having swap even if there is enough ram for all processes I've got machines with and without swap, but I typically run all servers with swap to handle ram-usage spikes I'm not expecting (you never know) while I run my laptop without swap when possible to avoid latency issues with swappiness. As with all things, its policy decisions and tradeoffs :-) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 3:32 ` Guy @ 2005-01-06 4:49 ` Mike Hardy 2005-01-09 21:07 ` Mark Hahn 0 siblings, 1 reply; 88+ messages in thread From: Mike Hardy @ 2005-01-06 4:49 UTC (permalink / raw) To: Guy; +Cc: linux-raid Guy wrote: > Maybe the concept of swapping is becoming obsolete? I think its definitely headed that way, if not already there for most new systems > to programmers. Most systems can support more RAM than most programs need. > With PC based systems (and some others I assume), 1 Gig of RAM is very > cheap! But I did note someone said you had to do something to break the > 2Gig boundary in Linux with x68 based systems. That's too bad. In a few To go bigger than 2GB on x86 you have to enable PAE (pointer address extensions? I forget the TLA expansion) which does have a speed hit and so is sub-optimal. Additionally, you still have limits on the amount of RAM any process can address and its more policy decisions and tradeoffs. Even with 64-bit, in my professional world (Java programming) I've had occasion to want 4GB heaps to work with for caching purposes, and programs are only just getting there. I think you're right then, the hardware and software have just met each other in the last year or so except for the edge cases. Bandwidth is the usual limiter at this point :-) > today (I think 64 Gig is about as much as is reasonable today). We should > reach the 64 bit limit in 42-56 years. Maybe it will be a long wait? :) :-) To make this more on topic, I'll say that I just switched all my servers (which had raid1 /boot and / but parallel JBOD swap) to mirrored swap after this discussion. All using simple mdadm/swapon/swapoff commands while they were humming, thanks to all the author's work. The servers are all doing fine, post-change. As further penance for taking up everyone's time, I'll point to the specific section of the software raid howto that discusses swapping on raid: http://www.tldp.org/HOWTO/Software-RAID-HOWTO-2.html#ss2.3 They succinctly say what was posted here - which is that you don't swap on raid for performance, but if you're looking for single-hdd machine survivability, swapping on raid1 is the only way. Cheers- -Mike ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 4:49 ` Mike Hardy @ 2005-01-09 21:07 ` Mark Hahn 0 siblings, 0 replies; 88+ messages in thread From: Mark Hahn @ 2005-01-09 21:07 UTC (permalink / raw) To: linux-raid > > Maybe the concept of swapping is becoming obsolete? > > I think its definitely headed that way, if not already there for most > new systems take a deep breath. this is manifestly untrue. in the current era, swap is a way to optimize the use of memory. please don't even think of its original meaning as a place to write out a process's complete VM in order to switch to another process's VM. swap is where the kernel puts less-used pages. having lots of memory does NOT magically mean that all pages are equally well-used. if you do actually have so much physical memory that the kernel never has any shortage of memory, well, bully for you, you've wasted big bucks. and it is waste. consider the page of my Firefox browser that contains code for interpreting devanagari unicode glyphs. it doesn't get much use, and so it should get swapped out. writing out a swap page is basically free, and it means I have one more page available for something more useful. since my frequency of reading devanagari pages is sort of low, that page can be used to cache, say, http://images.slashdot.org/title.gif. swapping is how the kernel optimizes space used by idle anonymous pages. if you understand that, it says absolutely everything you need to know: that swapping will always have some value, that it depends on high variance in the "temperature" of pages (and thus the concept of kernel memory "pressure"), that it doesn't apply to a system with no dirty anonymous pages. you can refuse to do this optimization, and your system will run poorer. the kernel can do this optimization poorly, and thus slow down, not speed up. you can waste your money on so much ram that the kernel never experiences memory pressure (but you'd be surprised how much ram that would require!) swapping is nearly free, since doing an async write doesn't slow anything else down (assuming good page choice, otherwise lightly loaded disks, nothing misconfigured like PIO.) swapping is a recognition that disk is drastically cheaper than ram. swapping does mean that idle anonymous pages could be corrupted by a flakey storage subsystem - but if that happens, you have other serious issues - what does it say about the pages comprising the text of your applications? remember that a big, hard-pressed system might have, say, a gigabyte of swap in use, but even a small desktop will have 50x that much in files exposed to the same hypothetical corruption. yes, I configure my systems with un-raided swap, because if disks are *that* flakey, I want to know about it. finally, ram prices (per GB) have been mostly stable for a couple years now. it's true that ram is faster, and systems are slowly increasing in ram size, but nothing dramatic is on the horizon. I run a supercomputer center that is buying a large amount of new hardware now. the old systems are almost 4 years old and have 1GB/cpu (4-way alphas). new systems will average about 4GB/cpu, and only a few of our users (HPC stuff way beyond desktops) would like more than 8GB/cpu. all of the ~6K cpus we buy will be in systems that have swap. regards, mark hahn. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 1:28 ` Mike Hardy 2005-01-06 3:32 ` Guy @ 2005-01-06 5:04 ` Alvin Oga 2005-01-06 6:18 ` Guy ` (2 more replies) 1 sibling, 3 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-06 5:04 UTC (permalink / raw) To: Mike Hardy; +Cc: linux-raid On Wed, 5 Jan 2005, Mike Hardy wrote: > There are those that think if they size the machine correctly, they > shouldn't need swap, and they're right. bingo > > I had 8 Meg of swap space. So 12 meg total available virtual memory. > > One day I added 16 Meg of RAM. So now I had 20 Meg of RAM. I deleted my > > swap space. Everyone told me I needed 20-40 Meg of swap space now! Swap > > space should be 2 time RAM size. How crazy, my memory requirements did not > > change, just the amount of memory. I used that system for a year or so like > > that. Go figure! the silly rule of 2x size of RAM == swap space came from the old days when memory was 10x the costs of disks or some silly cost performance that it made sense when grandpa was floating around by todays ram and disk pricing ... and cpu speeds ...2x memory sorta goes out the door c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 5:04 ` Alvin Oga @ 2005-01-06 6:18 ` Guy 2005-01-06 6:31 ` Alvin Oga 2005-01-06 9:38 ` swap on RAID (was Re: swp - Re: ext3 journal on software raid) Andy Smith 2005-01-09 21:21 ` swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Mark Hahn 2 siblings, 1 reply; 88+ messages in thread From: Guy @ 2005-01-06 6:18 UTC (permalink / raw) To: 'Alvin Oga', 'Mike Hardy'; +Cc: linux-raid HAY! DON'T CALL ME GRANDPA!!!! Not for a few more years at least! :) And I was there! And beyond! My first home computer had a 4K card and an 8K card, if I recall. It was 6800 based. I wonder if I still have it? I did use punch cards in college! Some computers had core memory, but no tube based computers. I am not that old!!! In the days of my 486-33, I paid $400 for 16Meg of RAM. The price doubled just after that when the only epoxy plant burned down or something. Now my video card has 64Meg of RAM! My first hard disk to break the $1 per meg boundary was a Maxtor 340Meg, cost me about $320. Now we are under the $1 per Gig boundary. Today, disk drives are so cheap you get 1 in a happy meal. :) Today, I guess disk space is 50-100 times cheaper per gig than RAM. Ouch! At the prices listed above, 1 gig of RAM would cost $25,000, and a 250Gig disk would cost $235,294. The price of RAM has dropped by 250 times. The price of disk drives dropped by over 1000 times. The future is going to be so cool! You said memory was 10x the cost of disks. In the example above, memory is 25x more than disk. Today it is about 100x. Maybe we should be swapping even more, now? :) Guy -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Alvin Oga Sent: Thursday, January 06, 2005 12:04 AM To: Mike Hardy Cc: linux-raid@vger.kernel.org Subject: Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) On Wed, 5 Jan 2005, Mike Hardy wrote: > There are those that think if they size the machine correctly, they > shouldn't need swap, and they're right. bingo > > I had 8 Meg of swap space. So 12 meg total available virtual memory. > > One day I added 16 Meg of RAM. So now I had 20 Meg of RAM. I deleted my > > swap space. Everyone told me I needed 20-40 Meg of swap space now! Swap > > space should be 2 time RAM size. How crazy, my memory requirements did not > > change, just the amount of memory. I used that system for a year or so like > > that. Go figure! the silly rule of 2x size of RAM == swap space came from the old days when memory was 10x the costs of disks or some silly cost performance that it made sense when grandpa was floating around by todays ram and disk pricing ... and cpu speeds ...2x memory sorta goes out the door c ya alvin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 6:18 ` Guy @ 2005-01-06 6:31 ` Alvin Oga 0 siblings, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-06 6:31 UTC (permalink / raw) To: Guy; +Cc: linux-raid hi ya guy On Thu, 6 Jan 2005, Guy wrote: > HAY! DON'T CALL ME GRANDPA!!!! Not for a few more years at least! wasn't calling ya grandpa :-) > And I was there! And beyond! My first home computer had a 4K card and an > 8K card, if I recall. It was 6800 based. I wonder if I still have it? I ahh .. that's 3rd generation stuff ... 4004 and Z8 and lots o no-namebrand what-you-ma-call-it-kits and i forgot what predated 6800 in motorola/zilog besides z8 .. getting too old > You said memory was 10x the cost of disks. In the example above, memory is > 25x more than disk. Today it is about 100x. 500x - 1000x in my book but that depends on how one counts > Maybe we should be swapping even more, now? :) disks are cheaper per byte of storage ??? 500MB for $50 250,000MB for $250 ( 250GB disks ) i leave it to you math wiz folks to generate $$$/MB c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* swap on RAID (was Re: swp - Re: ext3 journal on software raid) 2005-01-06 5:04 ` Alvin Oga 2005-01-06 6:18 ` Guy @ 2005-01-06 9:38 ` Andy Smith 2005-01-06 17:46 ` Mike Hardy 2005-01-07 1:31 ` confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) Alvin Oga 2005-01-09 21:21 ` swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Mark Hahn 2 siblings, 2 replies; 88+ messages in thread From: Andy Smith @ 2005-01-06 9:38 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 856 bytes --] On Wed, Jan 05, 2005 at 09:04:00PM -0800, Alvin Oga wrote: > On Wed, 5 Jan 2005, Mike Hardy wrote: > > > There are those that think if they size the machine correctly, they > > shouldn't need swap, and they're right. > > bingo Yet in an earlier reply you state that your machines have swap configured. There is a difference between these two statements: a) I need some amount of swap configured but don't expect a significant swap usage under normal load. b) I expect my server to always be using a significant amount of swap. I interpret your views as (a) but I interpret Mike's as "there are people who are saying that a correctly sized machine can have zero swap configured." Having no swap configured and merely using no swap in normal circumstances are very very different situations. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) 2005-01-06 9:38 ` swap on RAID (was Re: swp - Re: ext3 journal on software raid) Andy Smith @ 2005-01-06 17:46 ` Mike Hardy 2005-01-06 22:08 ` No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) Andrew Walrond 2005-01-07 1:31 ` confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) Alvin Oga 1 sibling, 1 reply; 88+ messages in thread From: Mike Hardy @ 2005-01-06 17:46 UTC (permalink / raw) To: linux-raid Andy Smith wrote: > I interpret your views as (a) but I interpret Mike's as "there are > people who are saying that a correctly sized machine can have zero > swap configured." > > Having no swap configured and merely using no swap in normal > circumstances are very very different situations. You are correct that I was getting at the zero swap argument - and I agree that it is vastly different from simply not expecting it. It is important to know that there is no inherent need for swap in the kernel though - it is simply used as more "memory" (albeit slower, and with some optimizations to work better with real memory) and if you don't need it, you don't need it. That said, I mentioned my servers run with swap for the same reason I run with raid. I don't plan on having a disk very often (if at all), and I don't plan on needing swap very often (if at all), but when it happens, I expect my machine to keep running. (or at least I hope it does) -Mike ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) 2005-01-06 17:46 ` Mike Hardy @ 2005-01-06 22:08 ` Andrew Walrond 2005-01-06 22:34 ` Jesper Juhl 0 siblings, 1 reply; 88+ messages in thread From: Andrew Walrond @ 2005-01-06 22:08 UTC (permalink / raw) To: linux-raid; +Cc: linux-kernel On Thursday 06 January 2005 17:46, Mike Hardy wrote: > > You are correct that I was getting at the zero swap argument - and I > agree that it is vastly different from simply not expecting it. It is > important to know that there is no inherent need for swap in the kernel > though - it is simply used as more "memory" (albeit slower, and with > some optimizations to work better with real memory) and if you don't > need it, you don't need it. > If I recollect a recent thread on LKML correctly, your 'no inherent need for swap' might be wrong. I think the gist was this: the kernel can sometimes needs to move bits of memory in order to free up dma-able ram, or lowmem. If I recall correctly, the kernel can only do this move via swap, even if there is stacks of free (non-dmaable or highmem) memory. I distinctly remember the moral of the thread being "Always mount some swap, if you can" This might have changed though, or I might have got it completely wrong. - I've cc'ed LKML incase somebody more knowledgeable can comment... Andrew Walrond ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) 2005-01-06 22:08 ` No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) Andrew Walrond @ 2005-01-06 22:34 ` Jesper Juhl 2005-01-06 22:57 ` Mike Hardy 0 siblings, 1 reply; 88+ messages in thread From: Jesper Juhl @ 2005-01-06 22:34 UTC (permalink / raw) To: Andrew Walrond; +Cc: linux-raid, linux-kernel On Thu, 6 Jan 2005, Andrew Walrond wrote: > On Thursday 06 January 2005 17:46, Mike Hardy wrote: > > > > You are correct that I was getting at the zero swap argument - and I > > agree that it is vastly different from simply not expecting it. It is > > important to know that there is no inherent need for swap in the kernel > > though - it is simply used as more "memory" (albeit slower, and with > > some optimizations to work better with real memory) and if you don't > > need it, you don't need it. > > > > If I recollect a recent thread on LKML correctly, your 'no inherent need for > swap' might be wrong. > > I think the gist was this: the kernel can sometimes needs to move bits of > memory in order to free up dma-able ram, or lowmem. If I recall correctly, > the kernel can only do this move via swap, even if there is stacks of free > (non-dmaable or highmem) memory. > > I distinctly remember the moral of the thread being "Always mount some swap, > if you can" > > This might have changed though, or I might have got it completely wrong. - > I've cc'ed LKML incase somebody more knowledgeable can comment... > http://kerneltrap.org/node/view/3202 -- Jesper Juhl ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) 2005-01-06 22:34 ` Jesper Juhl @ 2005-01-06 22:57 ` Mike Hardy 2005-01-06 23:15 ` Guy 0 siblings, 1 reply; 88+ messages in thread From: Mike Hardy @ 2005-01-06 22:57 UTC (permalink / raw) To: Jesper Juhl; +Cc: Andrew Walrond, linux-raid, linux-kernel Jesper Juhl wrote: > On Thu, 6 Jan 2005, Andrew Walrond wrote: > > >>On Thursday 06 January 2005 17:46, Mike Hardy wrote: >> >>>You are correct that I was getting at the zero swap argument - and I >>>agree that it is vastly different from simply not expecting it. It is >>>important to know that there is no inherent need for swap in the kernel >>>though - it is simply used as more "memory" (albeit slower, and with >>>some optimizations to work better with real memory) and if you don't >>>need it, you don't need it. >>> >> >>If I recollect a recent thread on LKML correctly, your 'no inherent need for >>swap' might be wrong. >> >>I think the gist was this: the kernel can sometimes needs to move bits of >>memory in order to free up dma-able ram, or lowmem. If I recall correctly, >>the kernel can only do this move via swap, even if there is stacks of free >>(non-dmaable or highmem) memory. >> >>I distinctly remember the moral of the thread being "Always mount some swap, >>if you can" >> >>This might have changed though, or I might have got it completely wrong. - >>I've cc'ed LKML incase somebody more knowledgeable can comment... >> > > > http://kerneltrap.org/node/view/3202 > Interesting - I was familiar with the original swappiness thread (http://kerneltrap.org/node/view/3000) but haven't seen anything since then (I mainly follow via kernel-traffic - enjoyable, but nowhere near real time). There's clearly been a bunch more discussion... Not to rehash the performance arguments, but it appears from my read of the kernel trap page referenced above that the primary argument for swap is still the performance argument - I didn't see anything referencing swap being necessary to move DMAable ram or lowmem. Was that posted previously on linux-kernel but not on kerneltrap? I'm still under the impression that "to swap or not" is a performance/policy/risk-management question, not a correctness question. If I'm wrong, I'd definitely like to know... -Mike ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) 2005-01-06 22:57 ` Mike Hardy @ 2005-01-06 23:15 ` Guy 2005-01-07 9:28 ` Andrew Walrond 0 siblings, 1 reply; 88+ messages in thread From: Guy @ 2005-01-06 23:15 UTC (permalink / raw) To: 'Mike Hardy', 'Jesper Juhl' Cc: 'Andrew Walrond', linux-raid, linux-kernel If I MUST/SHOULD have swap space.... Maybe I will create a RAM disk and use it for swap! :) :) :) Guy -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Mike Hardy Sent: Thursday, January 06, 2005 5:58 PM To: Jesper Juhl Cc: Andrew Walrond; linux-raid@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) Jesper Juhl wrote: > On Thu, 6 Jan 2005, Andrew Walrond wrote: > > >>On Thursday 06 January 2005 17:46, Mike Hardy wrote: >> >>>You are correct that I was getting at the zero swap argument - and I >>>agree that it is vastly different from simply not expecting it. It is >>>important to know that there is no inherent need for swap in the kernel >>>though - it is simply used as more "memory" (albeit slower, and with >>>some optimizations to work better with real memory) and if you don't >>>need it, you don't need it. >>> >> >>If I recollect a recent thread on LKML correctly, your 'no inherent need for >>swap' might be wrong. >> >>I think the gist was this: the kernel can sometimes needs to move bits of >>memory in order to free up dma-able ram, or lowmem. If I recall correctly, >>the kernel can only do this move via swap, even if there is stacks of free >>(non-dmaable or highmem) memory. >> >>I distinctly remember the moral of the thread being "Always mount some swap, >>if you can" >> >>This might have changed though, or I might have got it completely wrong. - >>I've cc'ed LKML incase somebody more knowledgeable can comment... >> > > > http://kerneltrap.org/node/view/3202 > Interesting - I was familiar with the original swappiness thread (http://kerneltrap.org/node/view/3000) but haven't seen anything since then (I mainly follow via kernel-traffic - enjoyable, but nowhere near real time). There's clearly been a bunch more discussion... Not to rehash the performance arguments, but it appears from my read of the kernel trap page referenced above that the primary argument for swap is still the performance argument - I didn't see anything referencing swap being necessary to move DMAable ram or lowmem. Was that posted previously on linux-kernel but not on kerneltrap? I'm still under the impression that "to swap or not" is a performance/policy/risk-management question, not a correctness question. If I'm wrong, I'd definitely like to know... -Mike - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) 2005-01-06 23:15 ` Guy @ 2005-01-07 9:28 ` Andrew Walrond 2005-02-28 20:07 ` Guy 0 siblings, 1 reply; 88+ messages in thread From: Andrew Walrond @ 2005-01-07 9:28 UTC (permalink / raw) To: linux-kernel Cc: Guy, 'Mike Hardy', 'Jesper Juhl', linux-raid, alan On Thursday 06 January 2005 23:15, Guy wrote: > If I MUST/SHOULD have swap space.... > Maybe I will create a RAM disk and use it for swap! :) :) :) Well, indeed, I had the same thought. As long as you could guarantee that the ram was of the highmem/non-dmaable type... But we're getting ahead of ourselves. I think we need an authoritive answer to the original premise. Perhaps Alan (cc-ed) might spare us a moment? Did I dream this up, or is it correct? "I think the gist was this: the kernel can sometimes needs to move bits of memory in order to free up dma-able ram, or lowmem. If I recall correctly, the kernel can only do this move via swap, even if there is stacks of free (non-dmaable or highmem) memory." Andrew ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) 2005-01-07 9:28 ` Andrew Walrond @ 2005-02-28 20:07 ` Guy 0 siblings, 0 replies; 88+ messages in thread From: Guy @ 2005-02-28 20:07 UTC (permalink / raw) To: 'Andrew Walrond', linux-kernel Cc: 'Mike Hardy', 'Jesper Juhl', linux-raid, alan I was just kidding about the RAM disk! I think swapping to a RAM disk can't work. Let's assume a page is swapped out. Now the first page of swap space is used, and memory is now allocated for it. Now assume the process frees the memory, the page in swap can now be freed, but the RAM disk still has the memory allocated, just not used. Now if the Kernel were to swap the first page of that RAM disk, it may be swapped to the first page of swap, which would change the data in the RAM disk which is being swapped out. So, I guess it can't be swapped, or must be re-swapped, or new memory is allocated. In any event, that 1 block will never be un-swapped, since it will never be needed. Each time the Kernel attempts to swap some of the RAM disk the RAM disk's memory usage will increase. This will continue until all of the RAM disk is used and there is no available swap space left. Swap will be full of swap. :) I hope that is clear! It makes my head hurt! I don't know about lomem or DMAable memory. But if special memory does exists.... It seems like if the Kernel can move memory to disk, it would be easier to move memory to memory. So, if special memory is needed, the Kernel should be able to relocate as needed. Maybe no code exists to do that, but I think it would be easier to do than to swap to disk (assuming you have enough free memory). Guy -----Original Message----- From: Andrew Walrond [mailto:andrew@walrond.org] Sent: Friday, January 07, 2005 4:28 AM To: linux-kernel@vger.kernel.org Cc: Guy; 'Mike Hardy'; 'Jesper Juhl'; linux-raid@vger.kernel.org; alan@lxorguk.ukuu.org.uk Subject: Re: No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) On Thursday 06 January 2005 23:15, Guy wrote: > If I MUST/SHOULD have swap space.... > Maybe I will create a RAM disk and use it for swap! :) :) :) Well, indeed, I had the same thought. As long as you could guarantee that the ram was of the highmem/non-dmaable type... But we're getting ahead of ourselves. I think we need an authoritive answer to the original premise. Perhaps Alan (cc-ed) might spare us a moment? Did I dream this up, or is it correct? "I think the gist was this: the kernel can sometimes needs to move bits of memory in order to free up dma-able ram, or lowmem. If I recall correctly, the kernel can only do this move via swap, even if there is stacks of free (non-dmaable or highmem) memory." Andrew ^ permalink raw reply [flat|nested] 88+ messages in thread
* confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) 2005-01-06 9:38 ` swap on RAID (was Re: swp - Re: ext3 journal on software raid) Andy Smith 2005-01-06 17:46 ` Mike Hardy @ 2005-01-07 1:31 ` Alvin Oga 2005-01-07 2:28 ` Andy Smith 1 sibling, 1 reply; 88+ messages in thread From: Alvin Oga @ 2005-01-07 1:31 UTC (permalink / raw) To: Andy Smith; +Cc: linux-raid On Thu, 6 Jan 2005, Andy Smith wrote: > On Wed, Jan 05, 2005 at 09:04:00PM -0800, Alvin Oga wrote: > > On Wed, 5 Jan 2005, Mike Hardy wrote: > > > > > There are those that think if they size the machine correctly, they > > > shouldn't need swap, and they're right. > > > > bingo > > Yet in an earlier reply you state that your machines have swap > configured. > > There is a difference between these two statements: since you're implying/saying i said those two statements below ( a and b ): you are one totally confused dude ... sorry to say ... i never said either of those two statements ... that is yur words and you're understanding of some mixture of lots of comments == grep "under normal load" sent-mail raid == ( pick any set of words of your "quote" for grep ) - it's not even in anybody comments posted, since i save all of my posts ( in sent-mail ) and not in anybody elses replies that is saved here ( thus my comment ... you're confused .. ) please refrain from making (re)quotes .. i didn't say so that i don't have to reply please do try to use: instead of "implying" i said something as in your "there is two different statments" in response to me which i didn't say either statments you're "quoting" incorrectly "from what i gather, i understand that ... " "i think this is ..." .. blah blah .. > a) I need some amount of swap configured but don't expect a > significant swap usage under normal load. > > b) I expect my server to always be using a significant > amount of swap. i personally do not expect any system i'm involved with to use any swap and if it does, i'd be adding more memory, as soon as they complain its running too slow when xxx or yyy job is running - they have choices of what they want done about it and it is NOT the same thing ... "not using swap" vs not creating one - i don't use swap and i rather the system not use it ... but i do create an itty bitty 250MB of swap partition even if there's is 2GB of system memory - in other cases ... like embedded systems ... it has no swap files .. no swap partitions adn things works just fine another example might be cell phones .. does those puppies have swap space ?? ( probably not ) c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) 2005-01-07 1:31 ` confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) Alvin Oga @ 2005-01-07 2:28 ` Andy Smith 2005-01-07 13:04 ` Alvin Oga 0 siblings, 1 reply; 88+ messages in thread From: Andy Smith @ 2005-01-07 2:28 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 4187 bytes --] On Thu, Jan 06, 2005 at 05:31:48PM -0800, Alvin Oga wrote: > > > On Thu, 6 Jan 2005, Andy Smith wrote: > > > On Wed, Jan 05, 2005 at 09:04:00PM -0800, Alvin Oga wrote: > > > On Wed, 5 Jan 2005, Mike Hardy wrote: > > > > > > > There are those that think if they size the machine correctly, they > > > > shouldn't need swap, and they're right. > > > > > > bingo > > > > Yet in an earlier reply you state that your machines have swap > > configured. > > > > There is a difference between these two statements: > > since you're implying/saying i said those two statements > below ( a and b ): No I was not implying that you said either of them. Why is this hard to understand? Look at Mike's response to me; he understood what I was getting at perfectly. I was only trying to point out to you that what you've said isn't consistent with things you said in other posts. > you are one totally confused dude ... sorry to say ... Look. It is quite simple. Mike above (which I leave quoted so you believe me) said: There are those that think if they size the machine correctly, they shouldn't need swap, and they're right. To which *you* replied: bingo *However* in an earlier mail in this thread you said that your machines do have swap configured. Mike has already clarified that he meant that these people say that no swap needs to be configured. So my point was that while you say "bingo" to Mike, you do not in reality do as Mike describes. > i never said either of those two statements ... that is yur words > and you're understanding of some mixture of lots of comments They were indeed my words and I never claimed otherwise. > == grep "under normal load" sent-mail raid == > ( pick any set of words of your "quote" for grep ) > > - it's not even in anybody comments posted, since i save > all of my posts ( in sent-mail ) and not in anybody elses > replies that is saved here > ( thus my comment ... you're confused .. ) > > please refrain from making (re)quotes .. i didn't say so that > i don't have to reply I didn't attribute any words to you. I quite clearly said they were my interpretation. A direct quote: There is a difference between these two statements: a) I need some amount of swap configured but don't expect a significant swap usage under normal load. b) I expect my server to always be using a significant amount of swap. I interpret your views as (a) but I interpret Mike's as "there are people who are saying that a correctly sized machine can have zero swap configured." You now go on to say: > i personally do not expect any system i'm involved with to use any > swap and if it does, i'd be adding more memory, as soon as they > complain its running too slow when xxx or yyy job is running > - they have choices of what they want done about it Which appears to me to be pretty much exactly what (a) above says. So I'm at a loss to understand why you bothered to write this email complaining about being misrepresented. Now that we have in one email original unedited quotes of you saying you agree with someone who suggests configuring no swap, and then quotes of you saying you do configure swap, I hope you will now concede my point that you are being inconsistent. If you don't agree, fine, I'm confident that what's been said speaks for itself and don't feel like pursuing the matter further. Especially if it's going to result in you telling ME that I "must be an idiot" and am "confused." > and it is NOT the same thing ... "not using swap" vs not creating one Yes, exactly my point from two emails ago. > - i don't use swap and i rather the system not use it ... > but i do create an itty bitty 250MB of swap partition > even if there's is 2GB of system memory So you do configure swap, this is now my point from 3 emails ago. Why it has taken 3 *long* emails to get you to answer one simple question and concede a blatant inconsistency in your argument is beyond me. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) 2005-01-07 2:28 ` Andy Smith @ 2005-01-07 13:04 ` Alvin Oga 0 siblings, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-07 13:04 UTC (permalink / raw) To: Andy Smith; +Cc: linux-raid On Fri, 7 Jan 2005, Andy Smith wrote: one last time ... stop saying/mis-quoting that i said what you're misquoting > > since you're implying/saying i said those two statements > > below ( a and b ): > > No I was not implying that you said either of them. ... note the above .. > Why is this hard to understand? good question ... to ask yourself .. > *However* in an earlier mail in this thread you said that your i did NOT say what you're quoting .... > > i never said either of those two statements ... that is yur words > > and you're understanding of some mixture of lots of comments > > They were indeed my words and I never claimed otherwise. see below > > please refrain from making (re)quotes .. i didn't say so that > > i don't have to reply > > I didn't attribute any words to you. I quite clearly said > they were my interpretation. A direct quote: stop this nonsense ... i never made the quotes you're re-citing incorrectly again and still, even if i told you to STOP making comments on my behalf as if i said that ... which i never did > There is a difference between these two statements: > > a) I need some amount of swap configured but don't > expect a significant swap usage under normal load. > > b) I expect my server to always be using a > significant amount of swap. > > I interpret your views how many times do i have to tell you ... it is NOT my view .... it is your (mis)interpretation, nothing close to what i said ... end of story .. for the last time do i need to send the lawyers to your doorstep to make you stop making incorrect statements and quotes that i never said c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 5:04 ` Alvin Oga 2005-01-06 6:18 ` Guy 2005-01-06 9:38 ` swap on RAID (was Re: swp - Re: ext3 journal on software raid) Andy Smith @ 2005-01-09 21:21 ` Mark Hahn 2005-01-09 22:20 ` Alvin Oga 2 siblings, 1 reply; 88+ messages in thread From: Mark Hahn @ 2005-01-09 21:21 UTC (permalink / raw) To: Alvin Oga; +Cc: linux-raid > the silly rule of 2x size of RAM == swap space came from the old days > when memory was 10x the costs of disks or some silly cost performance > that it made sense when grandpa was floating around ram is currently about $.1/MB, and disk is about $.0004/MB, so there is still a good reason to put idle pages onto swap disks. > by todays ram and disk pricing ... and cpu speeds ...2x memory sorta > goes out the door no. the cpu-speed argument is based on the fact that disk latencies are improving quite slowly, compared to ram latency (which is itself falling drastically behind cpu speeds.) this assumes that the argument for swap depends on swap latency, which it doesn't: swap pages are, ideally, *NEVER*READ*! the whole point is to choose anonymous pages which are so idle that they won't practically ever be touched. you *could* argue that the fraction of pages which can be profitably swapped is decreasing because "hot" items in memory are larger. it would be interesting to find out if that's true. certainly if only a few percent of ram is being used by idle anonymous pages, swapping has become irrelevant. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-09 21:21 ` swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Mark Hahn @ 2005-01-09 22:20 ` Alvin Oga 0 siblings, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-09 22:20 UTC (permalink / raw) To: Mark Hahn; +Cc: linux-raid hi ya mark On Sun, 9 Jan 2005, Mark Hahn wrote: > > the silly rule of 2x size of RAM == swap space came from the old days > > when memory was 10x the costs of disks or some silly cost performance > > that it made sense when grandpa was floating around > > ram is currently about $.1/MB, and disk is about $.0004/MB, > so there is still a good reason to put idle pages onto swap disks. yes.. as long as "swap(aka system thruput) speed" is not an issue and the alternative is to crash once memory options is used up :-) > > by todays ram and disk pricing ... and cpu speeds ...2x memory sorta > > goes out the door > > no. the cpu-speed argument is based on the fact that disk latencies > are improving quite slowly, compared to ram latency (which is itself > falling drastically behind cpu speeds.) the 2x memory capacity "old rule of thumb" i was referring to was if a system has 500MB of real memory, the old rule of thumb says create ( 2x 500 ) 1GB of disk swap - whether that 1GB of swap should be one partition or many spread out across the disk is another PhD paper c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-06 0:57 ` Guy 2005-01-06 1:28 ` Mike Hardy @ 2005-01-06 5:01 ` Alvin Oga 1 sibling, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-06 5:01 UTC (permalink / raw) To: Guy; +Cc: linux-raid hi ya guy On Wed, 5 Jan 2005, Guy wrote: > So, the question is: > Assume I have enough RAM to never need to swap. that depends on what you ae using your box/system for, and for you to figure out based on what the system is supposed to do > Do I need any swap space with Linux? it's not required ... many embedded systems runs without swap c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 15:33 ` Alvin Oga 2005-01-05 16:22 ` Michael Tokarev 2005-01-05 16:23 ` Andy Smith @ 2005-01-05 17:07 ` Guy 2005-01-05 17:21 ` Alvin Oga 2005-01-05 17:26 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves 2 siblings, 2 replies; 88+ messages in thread From: Guy @ 2005-01-05 17:07 UTC (permalink / raw) To: 'Alvin Oga'; +Cc: linux-raid RAID does not cause bad data! Bad data can get on any disk, even if it is part of a RAID system. The bad data does not come from the hard disk, CRCs prevent that. The problem is: Where does the bad data come from? Bad memory? No, everyone use ECC memory, right? Guy -----Original Message----- From: Alvin Oga [mailto:aoga@ns.Linux-Consulting.com] Sent: Wednesday, January 05, 2005 10:34 AM To: Guy Cc: linux-raid@vger.kernel.org Subject: RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) On Wed, 5 Jan 2005, Guy wrote: > I agree, but for a different reason. Your reason is new to me. .. > Loosing the swap disk would kill the system. if one is using swap space ... i'd add more memory .. before i'd use raid - swap is too slow and as you folks point out, it could die due to (unlikely) bad disk sectors in swap area > I don't want a down system due to a single disk failure. that's what raid's for :-) > I mirror everything, or RAID5. Normally, no downtime due to disk failures. the problem with mirror ( raid1 ).. or raid5 ... - if you have a bad diska ... all "bad data" will/could also get copied to the good disk - "bad data" is hard to figure out in code ... to prevent it from getting copied ... how does it know with 100% certainty - if you know why it's bad data, it's lot easier to know which data is more correct than the bad one - as everybody has pointed out .. bad data ( disk errors ) can occur for any number of gazillion reasons have fun raiding alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:07 ` Guy @ 2005-01-05 17:21 ` Alvin Oga 2005-01-05 17:32 ` Guy 2005-01-05 17:34 ` ECC: RE: ext3 blah blah blah Gordon Henderson 2005-01-05 17:26 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves 1 sibling, 2 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-05 17:21 UTC (permalink / raw) To: Guy; +Cc: 'Alvin Oga', linux-raid hi ya guy On Wed, 5 Jan 2005, Guy wrote: > RAID does not cause bad data! again .. that's not what i said .. the point i've been tring to say .. one MUST figure out "exactly" where the bad data or errors or crashes are coming from it will usually be bad ("cheap") parts or operator error or simple "slapped" together boxes > Bad data can get on any disk, even if it is part of a RAID system. > The bad data does not come from the hard disk, CRCs prevent that. > > The problem is: Where does the bad data come from? > Bad memory? No, everyone use ECC memory, right? that's what i was saying... but you do a better job even if one uses ecc... ecc can only fix certain errors, and non-correctable errors are flagged and not fixed ( burst errors are hard to fix ) and people that use ecc memory ... usually have higher-end motherboards and more memory in the system vs the $50 motherboard+cpu combo (disasters) from fries ( a local pc store ) c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:21 ` Alvin Oga @ 2005-01-05 17:32 ` Guy 2005-01-05 18:37 ` Alvin Oga 2005-01-05 17:34 ` ECC: RE: ext3 blah blah blah Gordon Henderson 1 sibling, 1 reply; 88+ messages in thread From: Guy @ 2005-01-05 17:32 UTC (permalink / raw) To: 'Alvin Oga'; +Cc: linux-raid You said this: " - as everybody has pointed out .. bad data ( disk errors ) can occur for any number of gazillion reasons have fun raiding Alvin" Bad data is not caused by disk errors. This seemed like you were blaming the hard disk. I understand you now. It seems we agree! Guy -----Original Message----- From: Alvin Oga [mailto:aoga@ns.Linux-Consulting.com] Sent: Wednesday, January 05, 2005 12:22 PM To: Guy Cc: 'Alvin Oga'; linux-raid@vger.kernel.org Subject: RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) hi ya guy On Wed, 5 Jan 2005, Guy wrote: > RAID does not cause bad data! again .. that's not what i said .. the point i've been tring to say .. one MUST figure out "exactly" where the bad data or errors or crashes are coming from it will usually be bad ("cheap") parts or operator error or simple "slapped" together boxes > Bad data can get on any disk, even if it is part of a RAID system. > The bad data does not come from the hard disk, CRCs prevent that. > > The problem is: Where does the bad data come from? > Bad memory? No, everyone use ECC memory, right? that's what i was saying... but you do a better job even if one uses ecc... ecc can only fix certain errors, and non-correctable errors are flagged and not fixed ( burst errors are hard to fix ) and people that use ecc memory ... usually have higher-end motherboards and more memory in the system vs the $50 motherboard+cpu combo (disasters) from fries ( a local pc store ) c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:32 ` Guy @ 2005-01-05 18:37 ` Alvin Oga 0 siblings, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-05 18:37 UTC (permalink / raw) To: Guy; +Cc: linux-raid On Wed, 5 Jan 2005, Guy wrote: > You said this: > " - as everybody has pointed out .. bad data ( disk errors ) > can occur for any number of gazillion reasons ... > Bad data is not caused by disk errors. This seemed like you were blaming > the hard disk. I understand you now. It seems we agree! i should have said "wrong data", where i don;t care why the data is not what one expects... due to failures, errors, problems, features, bugs ... and the point is .. if the data is wrong ... find out precisely why its wrong ... and experiment to confirm the suspicions - usually you will toss out one hardware item at a time to isolate the problem c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* ECC: RE: ext3 blah blah blah ... 2005-01-05 17:21 ` Alvin Oga 2005-01-05 17:32 ` Guy @ 2005-01-05 17:34 ` Gordon Henderson 2005-01-05 18:33 ` Alvin Oga 1 sibling, 1 reply; 88+ messages in thread From: Gordon Henderson @ 2005-01-05 17:34 UTC (permalink / raw) To: linux-raid On Wed, 5 Jan 2005, Alvin Oga wrote: > even if one uses ecc... ecc can only fix certain errors, > and non-correctable errors are flagged and not fixed > ( burst errors are hard to fix ) > > and people that use ecc memory ... usually have higher-end motherboards > and more memory in the system vs the $50 motherboard+cpu combo (disasters) > from fries ( a local pc store ) One thing thats been irritating me for a long time is that it's all very well using (and paying for!) ECC memory, but there are parts of the system that don't have ECC or parity - eg. the PCI bus, processor bus and internal paths, and so on... But where do you draw the line? Gordon ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ECC: RE: ext3 blah blah blah ... 2005-01-05 17:34 ` ECC: RE: ext3 blah blah blah Gordon Henderson @ 2005-01-05 18:33 ` Alvin Oga 0 siblings, 0 replies; 88+ messages in thread From: Alvin Oga @ 2005-01-05 18:33 UTC (permalink / raw) To: Gordon Henderson; +Cc: linux-raid On Wed, 5 Jan 2005, Gordon Henderson wrote: > One thing thats been irritating me for a long time is that it's all very > well using (and paying for!) ECC memory, but there are parts of the system > that don't have ECC or parity - eg. the PCI bus, processor bus and > internal paths, and so on... bingo !!! > But where do you draw the line? because the silly motherboard will nto work at all without those expensive registered ecc memory and you want that motherboard because it has the memory capacity you want ot the support to the fastest cpu around or blah features that no other mb has c ya alvin ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:07 ` Guy 2005-01-05 17:21 ` Alvin Oga @ 2005-01-05 17:26 ` David Greaves 2005-01-05 18:16 ` Peter T. Breuer 2005-01-05 18:26 ` Guy 1 sibling, 2 replies; 88+ messages in thread From: David Greaves @ 2005-01-05 17:26 UTC (permalink / raw) To: Guy; +Cc: linux-raid Guy wrote: >RAID does not cause bad data! > > Guy - how can you speak such heresy!! ;) Haven't you seen the special 'make_undetectable_error(float p)' function? >Bad data can get on any disk, even if it is part of a RAID system. >The bad data does not come from the hard disk, CRCs prevent that. > >The problem is: Where does the bad data come from? >Bad memory? No, everyone use ECC memory, right? > > I like to blame cosmic rays - I just like the image ;) Of course voltage fluctuations, e/m interference, thermal variations, mechanical interfaces, dust capacitance/resistance, insects shorts... anywhere inside the tin box between the media and the corners of the motherboard. It's amazing that some machines even boot. David ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:26 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves @ 2005-01-05 18:16 ` Peter T. Breuer 2005-01-05 18:28 ` Guy 2005-01-05 18:26 ` Guy 1 sibling, 1 reply; 88+ messages in thread From: Peter T. Breuer @ 2005-01-05 18:16 UTC (permalink / raw) To: linux-raid David Greaves <david@dgreaves.com> wrote: > Haven't you seen the special 'make_undetectable_error(float p)' function? dd if=/dev/urandom of=/dev/hda1 bs=512 count=1 skip=$RANDOM Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 18:16 ` Peter T. Breuer @ 2005-01-05 18:28 ` Guy 0 siblings, 0 replies; 88+ messages in thread From: Guy @ 2005-01-05 18:28 UTC (permalink / raw) To: 'Peter T. Breuer', linux-raid I think that is in some boot-up scripts! :) But only if you don't have mirrors! :) -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Peter T. Breuer Sent: Wednesday, January 05, 2005 1:16 PM To: linux-raid@vger.kernel.org Subject: Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves <david@dgreaves.com> wrote: > Haven't you seen the special 'make_undetectable_error(float p)' function? dd if=/dev/urandom of=/dev/hda1 bs=512 count=1 skip=$RANDOM Peter - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 88+ messages in thread
* RE: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 17:26 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves 2005-01-05 18:16 ` Peter T. Breuer @ 2005-01-05 18:26 ` Guy 1 sibling, 0 replies; 88+ messages in thread From: Guy @ 2005-01-05 18:26 UTC (permalink / raw) To: 'David Greaves'; +Cc: linux-raid You forgot one! Peter said: "There might be a small temporal displacement." This worries me! RED ALERT! Beam me up! Wait, I will take the shuttle craft please. "You cannot change the laws of physics!" - Scotty But, really, I do understand what Peter is saying. It just seemed too funny to me. And since I have disk read errors more than temporal displacement, I need RAID more than a temporal dampening field. Maybe a temporal phase converter? And, a single non-RAID disk can suffer from temporal displacement. I love Star Trek, so I love temporal displacements! :) Guy -----Original Message----- From: David Greaves [mailto:david@dgreaves.com] Sent: Wednesday, January 05, 2005 12:27 PM To: Guy Cc: linux-raid@vger.kernel.org Subject: Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Guy wrote: >RAID does not cause bad data! > > Guy - how can you speak such heresy!! ;) Haven't you seen the special 'make_undetectable_error(float p)' function? >Bad data can get on any disk, even if it is part of a RAID system. >The bad data does not come from the hard disk, CRCs prevent that. > >The problem is: Where does the bad data come from? >Bad memory? No, everyone use ECC memory, right? > > I like to blame cosmic rays - I just like the image ;) Of course voltage fluctuations, e/m interference, thermal variations, mechanical interfaces, dust capacitance/resistance, insects shorts... anywhere inside the tin box between the media and the corners of the motherboard. It's amazing that some machines even boot. David ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) 2005-01-05 15:17 ` Guy 2005-01-05 15:33 ` Alvin Oga @ 2005-01-05 15:48 ` Peter T. Breuer 1 sibling, 0 replies; 88+ messages in thread From: Peter T. Breuer @ 2005-01-05 15:48 UTC (permalink / raw) To: linux-raid Guy <bugzilla@watkins-home.com> wrote: > I agree, but for a different reason. Your reason is new to me. > I don't want a down system due to a single disk failure. > Loosing the swap disk would kill the system. > > Maybe this is Peter's cause of frequent corruption? I wouldn't have aid there were frequent failures! There are relatively frequent disk errors, at the rate of probably 10 bits per hundred machines per week. I do not think that is very frequent. Peter ^ permalink raw reply [flat|nested] 88+ messages in thread
[parent not found: <41D45C1F.5030307-XAri/EZa3C4vJsYlp49lxw@public.gmane.org>]
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard [not found] ` <41D45C1F.5030307-XAri/EZa3C4vJsYlp49lxw@public.gmane.org> @ 2004-12-30 20:54 ` berk walker 2005-01-01 13:39 ` Helge Hafting 1 sibling, 0 replies; 88+ messages in thread From: berk walker @ 2004-12-30 20:54 UTC (permalink / raw) To: Michael Tokarev Cc: Peter T. Breuer, linux-raid-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, dm-crypt-4q3lyFh4P1g Michael Tokarev wrote: > Peter T. Breuer wrote: > >> In gmane.linux.raid Georg C. F. Greve <greve-BSDwwRMYa8fNLxjTenLetw@public.gmane.org> wrote: >> >> Yes, well, don't put the journal on the raid partition. Put it >> elsewhere (anyway, journalling and raid do not mix, as write ordering >> is not - deliberately - preserved in raid, as far as I can tell). > > > This is a sort of a nonsense, really. Both claims, it seems. > I can't say for sure whenever write ordering is preserved by > raid -- it should, and if it isn't, it's a bug and should be > fixed. Nothing else is wrong with placing journal into raid > (the same as the filesystem in question). Suggesting to remove > journal just isn't fair: the journal is here for a reason. > And, finally, the kernel should not crash. If something like > this is unsupported, it should refuse to do so, instead of > crashing randomly. > > /mjt > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > I might have missed some of this thread.... but have you tried this on a completely different box? I have seen, and am fighting some problems such as yours, and having nothing to do with raid. If you haven't, then try it. You might get different results. Hardware can sometimes be a dog to chase down, problemwise. b- ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard [not found] ` <41D45C1F.5030307-XAri/EZa3C4vJsYlp49lxw@public.gmane.org> 2004-12-30 20:54 ` PROBLEM: Kernel 2.6.10 crashing repeatedly and hard berk walker @ 2005-01-01 13:39 ` Helge Hafting 1 sibling, 0 replies; 88+ messages in thread From: Helge Hafting @ 2005-01-01 13:39 UTC (permalink / raw) To: Michael Tokarev Cc: Peter T. Breuer, linux-raid-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, dm-crypt-4q3lyFh4P1g On Thu, Dec 30, 2004 at 10:50:55PM +0300, Michael Tokarev wrote: > Peter T. Breuer wrote: > >In gmane.linux.raid Georg C. F. Greve <greve-BSDwwRMYa8fNLxjTenLetw@public.gmane.org> wrote: > > > >Yes, well, don't put the journal on the raid partition. Put it > >elsewhere (anyway, journalling and raid do not mix, as write ordering > >is not - deliberately - preserved in raid, as far as I can tell). > > This is a sort of a nonsense, really. Both claims, it seems. > I can't say for sure whenever write ordering is preserved by > raid -- it should, and if it isn't, it's a bug and should be > fixed. Nothing else is wrong with placing journal into raid > (the same as the filesystem in question). Suggesting to remove > journal just isn't fair: the journal is here for a reason. > And, finally, the kernel should not crash. If something like > this is unsupported, it should refuse to do so, instead of > crashing randomly. Write ordering trouble shouldn't crash the kernel, the way I understand it. Your journalled fs could be lost/inconsistent if the machine crashes for other reasons, due to bad write ordering. But the ordering trouble shouldn't cause a crash, and all should be fine as soon as all the writes complete without other incidents. Helge Hafting ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2004-12-30 17:39 ` Peter T. Breuer 2004-12-30 17:53 ` Sandro Dentella 2004-12-30 19:50 ` Michael Tokarev @ 2005-01-07 6:21 ` Clemens Schwaighofer 2005-01-07 9:39 ` Andy Smith 2 siblings, 1 reply; 88+ messages in thread From: Clemens Schwaighofer @ 2005-01-07 6:21 UTC (permalink / raw) To: Peter T. Breuer, linux-raid -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/31/2004 02:39 AM, Peter T. Breuer wrote: > In gmane.linux.raid Georg C. F. Greve <greve@fsfeurope.org> wrote: > >>The message I saw on the remote console when it crashed with pure ext3 >>on raid5 was: >> >> Assertion failure in journal_start() at fs/jbd/transaction.c:271: "handle->h_transaction->t_journal == journal" >> > > Yes, well, don't put the journal on the raid partition. Put it > elsewhere (anyway, journalling and raid do not mix, as write ordering > is not - deliberately - preserved in raid, as far as I can tell). Thats a very new claim. I never ever heard of that. I have a lot of boxes running with software raid (1 or 5) and they run either XFS or ext3 on it, and since one year I never had a single problem (and they all use 2.6.7 or 2.6.8.1 kernels). - -- [ Clemens Schwaighofer -----=====:::::~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp http://www.tbwajapan.co.jp ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3ipTjBz/yQjBxz8RAsExAJ9ZhniY/vsm9TIpRtHhGsfdVjws6wCeO4RS rJ/o4roBjSBo3z5os/E6tKk= =d3Rn -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard 2005-01-07 6:21 ` Clemens Schwaighofer @ 2005-01-07 9:39 ` Andy Smith 0 siblings, 0 replies; 88+ messages in thread From: Andy Smith @ 2005-01-07 9:39 UTC (permalink / raw) To: linux-raid [-- Attachment #1: Type: text/plain, Size: 550 bytes --] On Fri, Jan 07, 2005 at 03:21:08PM +0900, Clemens Schwaighofer wrote: > On 12/31/2004 02:39 AM, Peter T. Breuer wrote: > > Yes, well, don't put the journal on the raid partition. Put it > > elsewhere (anyway, journalling and raid do not mix, as write ordering > > is not - deliberately - preserved in raid, as far as I can tell). > > Thats a very new claim. I never ever heard of that. Yes, and neither have most people I talked to about this, which is why I think this deserves to be explored more and any gotchas documented somewhere. [-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 88+ messages in thread
end of thread, other threads:[~2005-02-28 20:07 UTC | newest]
Thread overview: 88+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-30 0:31 PROBLEM: Kernel 2.6.10 crashing repeatedly and hard Georg C. F. Greve
2004-12-30 16:23 ` Georg C. F. Greve
2004-12-30 17:39 ` Peter T. Breuer
2004-12-30 17:53 ` Sandro Dentella
2004-12-30 18:31 ` Peter T. Breuer
2004-12-30 19:50 ` Michael Tokarev
2004-12-30 21:39 ` Peter T. Breuer
2005-01-02 19:42 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith
2005-01-02 20:18 ` Peter T. Breuer
2005-01-03 0:30 ` Andy Smith
2005-01-03 6:41 ` Neil Brown
2005-01-03 8:37 ` Peter T. Breuer
2005-01-03 8:03 ` Peter T. Breuer
2005-01-03 8:58 ` Guy
2005-01-03 10:18 ` Partiy error detection - was " Brad Campbell
2005-01-03 12:11 ` Michael Tokarev
2005-01-03 14:23 ` Peter T. Breuer
2005-01-03 18:30 ` maarten
2005-01-03 21:36 ` Michael Tokarev
2005-01-05 5:50 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison
2005-01-05 13:41 ` Michael Tokarev
2005-01-05 13:57 ` [help] [I2O] Adaptec 2400A on FC3 Angelo Piraino
2005-01-05 19:15 ` Debian Sarge mdadm raid 10 assembling at boot problem Roger Ellison
2005-01-05 9:56 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith
2005-01-05 10:44 ` Alvin Oga
2005-01-05 10:56 ` Brad Campbell
2005-01-05 11:39 ` Alvin Oga
2005-01-05 12:02 ` Brad Campbell
2005-01-05 13:23 ` Alvin Oga
2005-01-05 13:33 ` Brad Campbell
2005-01-05 14:44 ` parts -- " Alvin Oga
2005-01-19 4:46 ` Clemens Schwaighofer
2005-01-19 5:05 ` Alvin Oga
2005-01-19 5:49 ` Clemens Schwaighofer
2005-01-19 7:08 ` Alvin Oga
2005-01-05 13:36 ` Swap should be mirrored or not? (was Re: ext3 journal on software raid) Andy Smith
2005-01-05 14:12 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Erik Mouw
2005-01-05 14:37 ` Michael Tokarev
2005-01-05 14:55 ` errors " Alvin Oga
2005-01-05 17:11 ` Erik Mouw
2005-01-06 5:41 ` Brad Campbell
2005-01-05 15:17 ` Guy
2005-01-05 15:33 ` Alvin Oga
2005-01-05 16:22 ` Michael Tokarev
2005-01-05 17:23 ` Peter T. Breuer
2005-01-05 16:23 ` Andy Smith
2005-01-05 16:30 ` Andy Smith
2005-01-05 17:04 ` swp - " Alvin Oga
2005-01-05 17:26 ` Andy Smith
2005-01-05 18:32 ` Alvin Oga
2005-01-05 22:35 ` Andy Smith
2005-01-06 0:57 ` Guy
2005-01-06 1:28 ` Mike Hardy
2005-01-06 3:32 ` Guy
2005-01-06 4:49 ` Mike Hardy
2005-01-09 21:07 ` Mark Hahn
2005-01-06 5:04 ` Alvin Oga
2005-01-06 6:18 ` Guy
2005-01-06 6:31 ` Alvin Oga
2005-01-06 9:38 ` swap on RAID (was Re: swp - Re: ext3 journal on software raid) Andy Smith
2005-01-06 17:46 ` Mike Hardy
2005-01-06 22:08 ` No swap can be dangerous (was Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid)) Andrew Walrond
2005-01-06 22:34 ` Jesper Juhl
2005-01-06 22:57 ` Mike Hardy
2005-01-06 23:15 ` Guy
2005-01-07 9:28 ` Andrew Walrond
2005-02-28 20:07 ` Guy
2005-01-07 1:31 ` confused Re: swap on RAID (was Re: swp - Re: ext3 journal on software raid) Alvin Oga
2005-01-07 2:28 ` Andy Smith
2005-01-07 13:04 ` Alvin Oga
2005-01-09 21:21 ` swp - Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Mark Hahn
2005-01-09 22:20 ` Alvin Oga
2005-01-06 5:01 ` Alvin Oga
2005-01-05 17:07 ` Guy
2005-01-05 17:21 ` Alvin Oga
2005-01-05 17:32 ` Guy
2005-01-05 18:37 ` Alvin Oga
2005-01-05 17:34 ` ECC: RE: ext3 blah blah blah Gordon Henderson
2005-01-05 18:33 ` Alvin Oga
2005-01-05 17:26 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves
2005-01-05 18:16 ` Peter T. Breuer
2005-01-05 18:28 ` Guy
2005-01-05 18:26 ` Guy
2005-01-05 15:48 ` Peter T. Breuer
[not found] ` <41D45C1F.5030307-XAri/EZa3C4vJsYlp49lxw@public.gmane.org>
2004-12-30 20:54 ` PROBLEM: Kernel 2.6.10 crashing repeatedly and hard berk walker
2005-01-01 13:39 ` Helge Hafting
2005-01-07 6:21 ` Clemens Schwaighofer
2005-01-07 9:39 ` Andy Smith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).