Re: spare group
Neil Brown írta: On Tuesday June 12, [EMAIL PROTECTED] wrote: I am very sorry, but it wont works with .9 superblocks also :( We missing something small, but important here. Before you start to code. mdadm was running in monitor mode, and reported a Fail. mdadm is the latest version, 2.6.2. tg Hmmm. [tests code] Yes, you are right. It looks like a bug was introduced in 2.6 which broke various aspects of --monitor. I guess I need to add some --monitor tests to my regression test suite. This patch should fix it. Thanks again, NeilBrown Thanks, the patch is working. tg - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: spare group
Neil Brown írta: (reads code). Ahhh. You are using version-1 superblocks aren't you? That code only works for version-0.90 superblocks. That was careless of me. It shouldn't be hard to make it work more generally, but it looks like it will be slightly more than trivial. I'll try to get you a patch in the next day or so (feel free to remind me if I seem to have forgotten). Thanks for testing and reporting this problem. NeilBrown # mdadm26 --detail /dev/md0 /dev/md0: Version : 00.90.03 Creation Time : Tue Jun 12 10:31:08 2007 Raid Level : raid5 Array Size : 19534848 (18.63 GiB 20.00 GB) Used Dev Size : 9767424 (9.31 GiB 10.00 GB) Raid Devices : 3 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Jun 12 10:33:35 2007 State : clean Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K UUID : 5fd83926:01739a55:36458d87:119f8994 (local to host ursula) Events : 0.4 Number Major Minor RaidDevice State 0 810 active sync /dev/sda1 1 8 171 active sync /dev/sdb1 2 8 332 active sync /dev/sdc1 3 8 49- spare /dev/sdd1 /dev/md1: Version : 00.90.03 Creation Time : Tue Jun 12 10:31:29 2007 Raid Level : raid5 Array Size : 19534848 (18.63 GiB 20.00 GB) Used Dev Size : 9767424 (9.31 GiB 10.00 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Tue Jun 12 10:36:18 2007 State : clean, degraded Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K UUID : 815d6fc4:a55c2602:36458d87:119f8994 (local to host ursula) Events : 0.6 Number Major Minor RaidDevice State 0 8 650 active sync /dev/sde1 1 8 811 active sync /dev/sdf1 2 002 removed 3 8 97- faulty spare /dev/sdg1 ARRAY /dev/md1 level=raid5 num-devices=3 spare-group=ubul UUID=815d6fc4:a55c2602:36458d87:119f8994 ARRAY /dev/md0 level=raid5 num-devices=3 spares=1 spare-group=ubul UUID=5fd83926:01739a55:36458d87:119f8994 I am very sorry, but it wont works with .9 superblocks also :( We missing something small, but important here. Before you start to code. mdadm was running in monitor mode, and reported a Fail. mdadm is the latest version, 2.6.2. tg - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
strange test results
Hi! I am running tests on our new test device. The device has 2x2 core Xeon, intel 5000 chipset, two 3ware sata raid card on pcie, and 15 sata2 disks, running debian etch. More info at the bottom. The first phase of the test is probing various raid levels. So i configured the cards to 15 JBOD disks, and hacked together a testing script. The script builds raid arrays, waits for sync, and then runs this command: iozone -eM -s 4g -r 1024 -i0 -i1 -i2 -i8 -t16 -+u The graphs of the results here: http://gergely.tomka.hu/dt/index.html And i have a lots of questions. http://gergely.tomka.hu/dt/1.html This graph is crazy, like thunderbolts. But the raid50 is generally slower than raid5. Why? http://gergely.tomka.hu/dt/3.html This is the only graph i can explain :) http://gergely.tomka.hu/dt/4.html With random readers, why raid0 slowing down? And why raid10 faster than raid0? http://gergely.tomka.hu/dt/2.html Why raid6 cant became faster, with multiple disks, as raid5 50? So lots of questions. I am generally surprised by the non-linearity of some results and the lack of acceleration with more disks on other results. And now, the details: Hardware: Base Board Information Manufacturer: Supermicro Product Name: X7DB8 Processor Information Socket Designation: LGA771/CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: 64 0F 00 00 FF FB EB BF Signature: Type 0, Family 15, Model 6, Stepping 4 (two cpus) Memory Device Array Handle: 0x0017 Error Information Handle: No Error Total Width: 72 bits Data Width: 64 bits Size: 1024 MB Form Factor: DIMM Set: 1 Locator: DIMM x 4 Bank Locator: Bank1 Type: DDR2 Type Detail: Synchronous Speed: 533 MHz (1.9 ns) Manufacturer: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified (two of this also) ursula:~# tw_cli show Ctl ModelPorts Drives Units NotOpt RRate VRate BBU c09590SE-8ML 8 77 01 1 - c19590SE-8ML 8 88 01 1 - The tests generally: mdadm mkfs.xfs blockdev --setra 524288 md (maybe not a good idea for multiple arrays) do iozone test raid10 is two disks raid1s in raid0 and raid50 is three disk raid6s in raid0. These test runs for a week, and now slowly finishing. For this reason, replicatong the test to filter out accidents not a good option. Any comments? -- Tomka Gergely, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sw raid0 read bottleneck
Hi! I am currently testing 3ware raid cards. Now i have 15 disks, and on these a swraid0. The write speed seems good (700 MBps), but the read performance only 350 MBps. Another problem when i try to read with two process, then the _sum_ of the read speeds fall back to 200 MBps. So there is a bottleneck, or something i need to know, but i dont have ideas. The details: /dev/md0: Version : 00.90.03 Creation Time : Tue Mar 13 16:57:32 2007 Raid Level : raid0 Array Size : 7325797440 (6986.43 GiB 7501.62 GB) Raid Devices : 15 Total Devices : 15 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Mar 13 16:57:32 2007 State : clean Active Devices : 15 Working Devices : 15 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64K # uname -a Linux ursula 2.6.18-4-686-bigmem #1 SMP Wed Feb 21 17:30:22 UTC 2007 i686 GNU/Linux # xfs_info /mnt/ meta-data=/dev/md0 isize=256agcount=32, agsize=57232784 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1831449088, imaxpct=25 = sunit=16 swidth=240 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=983040 blocks=0, rtextents=0 (all software Debian Etch) four Intel(R) Xeon(TM) CPU 3.00GHz two 3ware 9590SE-8ML on PCIe Intel Corporation 5000P Chipset -- Tomka Gergely, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sw raid0 read bottleneck
On Tue, 13 Mar 2007, Justin Piszcz wrote: Have you tried increasing your readahead values for the md device? Yes. No real change. According to my humble mental image, readahead not a too useful thing, when we read 1-4 thread with sdd. The io subsystem already reading with the possible maximum speed, so don't have time to read ahead. Correct me, if i wrong. -- Tomka Gergely, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sw raid0 read bottleneck
On Tue, 13 Mar 2007, Tomka Gergely wrote: On Tue, 13 Mar 2007, Justin Piszcz wrote: Have you tried increasing your readahead values for the md device? Yes. No real change. According to my humble mental image, readahead not a too useful thing, when we read 1-4 thread with sdd. The io subsystem already reading with the possible maximum speed, so don't have time to read ahead. Correct me, if i wrong. I was wrong, readahead can speed things up, to 450 MBps. -- Tomka Gergely, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sw raid0 read bottleneck
On Wed, 14 Mar 2007, Neil Brown wrote: On Tuesday March 13, [EMAIL PROTECTED] wrote: On Tue, 13 Mar 2007, Tomka Gergely wrote: On Tue, 13 Mar 2007, Justin Piszcz wrote: Have you tried increasing your readahead values for the md device? Yes. No real change. According to my humble mental image, readahead not a too useful thing, when we read 1-4 thread with sdd. The io subsystem already reading with the possible maximum speed, so don't have time to read ahead. Correct me, if i wrong. I was wrong, readahead can speed things up, to 450 MBps. Can you tell use what read-ahead size you needed? 15 drives and 64K chunks gives 960K per stripe. The raid0 code should set the read-ahead to twice that: 1920K which I would have thought would be enough, but apparently not. blockdev --setra 262144 /dev/md0 gives me 650+ MB/s with 4 threads (paralell running sdd). Lower values give lower speeds, greater values not giving higher speeds. -- Tomka Gergely, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
beginner error detection
Hi! I have a simple sw raid1, over two sata disks. One of the disks started to complain (s.m.a.r.t. errors). I think in the near future i witness a disk failure. But i don't know how this thing is happening with raid1, so i have some questions. If these questions answered somewhere (faq, manpage, url), then feel free to redirect me to this source(s). Can the raid1 detect and handle disk errors? If one block goes wrong, how can the raid1 driver choose which was the correct, original value? Sata systems can die gracefully? When in a good scsi system happens a total disk failure, then the scsi makes the disk fail, mdadm removes the disk from the array, and in the morning i see a nice e-mail. When a PATA disk dies, the system goes down, so i need to call a cab. I dont know how the sata behaves in this situation. The kernel 2.6.20 (with skas patch), the controller : nVidia Corporation CK804 Serial ATA Controller (rev f3) Thanks. -- Tomka Gergely, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
