* Re: Why do I get different results for 'mdadm --detail' & 'mdadm --examine' for the same array?
From: jeffs_linux @ 2011-06-12 1:49 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1307842966.26762.1462147225@webmail.messagingengine.com>
and, one more bit of information
ls -al /dev/md*
brw-rw---- 1 root disk 9, 126 Jun 11 16:52 /dev/md126
brw-rw---- 1 root disk 9, 127 Jun 11 16:51 /dev/md127
/dev/md:
total 0
drwxr-xr-x 2 root root 60 Jun 11 16:52 ./
drwxr-xr-x 22 root root 5560 Jun 11 17:15 ../
lrwxrwxrwx 1 root root 8 Jun 11 16:52 0_0 -> ../md126
Jeff
^ permalink raw reply
* Re: Triple-parity raid6
From: David Brown @ 2011-06-12 9:05 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4DF39E8B.6090106@gmail.com>
On 11/06/11 18:57, Joe Landman wrote:
> On 06/11/2011 12:31 PM, David Brown wrote:
>
>> What has changed over the years is that there is no longer such a need
>> for manual assembly code to get optimal speed out of the cpu. While
>
> Hmmm ... I've done studies on this using an incredibly simple function
> (Riemann Zeta Function c.f. http://scalability.org/?p=470 ). The short
> version is that hand optimized SSE2 is ~4x faster (for this case) than
> best optimization of high level code. Hand optimized assembler is even
> better.
>
>> writing such assembly is fun, it is time-consuming to write and hard to
>> maintain, especially for code that must run on so many different
>> platforms.
>
> Yes, it is generally hard to write and maintain. But it you can get the
> rest of the language semantics out of the way. If you look at the tests
> that Linux does when it starts up, you can see a fairly wide
> distribution in the performance.
>
> raid5: using function: generic_sse (13356.000 MB/sec)
> raid6: int64x1 3507 MB/s
> raid6: int64x2 3886 MB/s
> raid6: int64x4 3257 MB/s
> raid6: int64x8 3054 MB/s
> raid6: sse2x1 8347 MB/s
> raid6: sse2x2 9695 MB/s
> raid6: sse2x4 10972 MB/s
>
> Some of these are hand coded assembly. See
> ${KERNEL_SOURCE}/drivers/md/raid6sse2.c and look at the
> raid6_sse24_gen_syndrome code.
>
> Really, to get the best performance out of the system, requires a fairly
> deep understanding of how the processor/memory system operates. These
> functions do use the SSE registers, but we can have only so many SSE
> operations in flight at once. These processors can generally have quite
> a few simultaneous operations in flight at once, so a knowledge about
> that, and the mix of operations, and how the interact with the
> instruction scheduler in the hardware, is fairly essential to getting
> good performance.
>
I am not suggesting that hand-coding assembly won't make the
calculations faster - just that better compiler optimisations (which
will automatically make use of sse instructions) will make the generic
code closer to the theoretical maximum.
Out of curiosity, have you re-tried your zeta function code using a more
modern version of gcc? A lot has happened with gcc since 4.1 - in
particular, the "graphite" code in gcc 4.4 will make a big difference to
code that loops through a lot of data (it re-arranges the loops to
unroll inner blocks, and to make loop strides match cache sizes).
>>
>>> We are interested in working on this capability (and more generic
>>> capability) as well.
>>>
>>> Is anyone in particular starting to design/code this? Please let me
>>> know.
>>>
>>
>> Well, I am currently trying to write up some of the maths - I started
>> the thread because I had been playing around with the maths, and thought
>> it should work. I made a brief stab at writing a
>> "raid7_int$#_gen_syndrome()" function, but I haven't done any testing
>> with it (or even tried to compile it) - first I want to be sure of the
>> algorithms.
>
> I've been coding various bits as "pseudocode" using Octave. Makes
> checking with the built in Galios functions pretty easy.
>
> I haven't looked at the math behind the triple parity syndrome calc yet,
> though I'd imagine someone has, and can write it down. If someone hasn't
> done that yet, its a good first step. Then we can code the simple
> version from there with test drivers/cases, and then start optimizing
> the implementation.
>
>
^ permalink raw reply
* Read and get back!!
From: BENG.helpdesk @ 2011-06-12 18:09 UTC (permalink / raw)
To: Koh Beng Seng helpdesk@webmaster.net
Read and get back!!
I am Mr. KOH Beng Seng Independent Non-executive Director Chairman of Bank of China Ltd, Hong Kong.
An Iraqi named Abrahem Hussein Raheem, a business man made a numbered fixed deposit of Sixty Five Million Five Hundred Thousand United State Dollars only in my branch. Upon maturity several notices was sent to him, even during the war, Five years ago (2006). Again after the war another notification was sent and still no response came from him. We later found out that Ahmed Sadoun Salih and his family had been killed during the war in Gunfire that hit their home at Mukaradeeb where his personal oil-well was.
After further investigation it was also discovered that Abrahem Hussein Raheem did not declare any next of kin in his official papers including the paper work of his bank deposit. And he also confided in me the last time he was at my office that no one except me knew of his deposit in my bank. So, Sixty Five Million Five Hundred Thousand United State Dollars is still lying in my bank and no one will ever come forward to claim it. What bothers me is that according to the laws of my country at the expiration seven years six months the funds will revert to the ownership of the Hong Kong Government if nobody applies to claim the funds.
I want to assure you that this project is real and one hundred percent risk free and does not relate to any breach of law or proceeds from drugs. It is a matter of necessity to contact you for assistance without any further investigations about your person, it is therefore necessary that you tell me a little about yourself, I hope no form of betrayal will be experienced in the course of our collaboration, I must give you my trust because this transaction is no joke and such opportunity comes once in a life time.
My proposal to you is that I prepared to front you as the sole beneficiary of my deceased client so that i can instruct BANK OF CHINA to release the deposit to you as the closest surviving relation or business partner. Upon receipt of the deposit, I am prepared to share the money with you in half 50/50 percentage. If interested do send me your full names, current home address, phone number, your occupation to this email account: kohbseng@yahoo.com.hk
Your earliest reply will be appreciated.
Yours Truly,
Mr. KOH Beng Seng,
Independent Non-Executive Director
Chairman of the Risk Committee, Hong Kong
Email: kohbseng@yahoo.com.hk
^ permalink raw reply
* md 3.2.1 and xfs kernel panic on Linux 2.6.38
From: fibreraid @ 2011-06-12 18:50 UTC (permalink / raw)
To: linux-raid, linux-xfs; +Cc: fibre raid
Hi All,
I am benchmarking md RAID with XFS on a server running Linux 2.6.38
kernel. The server has 24 x HDD's, dual 2.4GHz 6-core CPUs, and 24GB
RAM.
I created an md0 array using RAID 5, 64k chunk, 23 active drives, and
1 hot-spare. I then created a LVM2 volume group from this md0, and
created an LV out of it. The volume was formatted XFS as follows:
/sbin/mkfs.xfs –f –l lazy-count=1 -l size=128m -s size=4096
/dev/mapper/pool1-vol1
I then mounted it as follows:
/dev/mapper/pool1-vol1 on /volumes/pool1/vol1 type xfs
(rw,_netdev,noatime,nodiratime,osyncisdsync,nobarrier,logbufs=8,delaylog)
Once md synchronization was complete, I removed one of the active 23
drives. After attempting some IO, the md0 array began to rebuild to
the hot-spare. In a few hours, it was complete and the md0 array was
listed as active and healthy again (though now lacking a hot-spare
obviously).
As a test, I removed one more drive to see what would happen. As
expected, mdadm reported the array as active but degraded, and since
there was no hot-spare available, there was no rebuilding happening.
root@TESTBA16:~# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sat Jun 11 19:06:46 2011
Raid Level : raid5
Array Size : 8595566848 (8197.37 GiB 8801.86 GB)
Used Dev Size : 390707584 (372.61 GiB 400.08 GB)
Raid Devices : 23
Total Devices : 24
Persistence : Superblock is persistent
Update Time : Sat Jun 11 23:30:14 2011
State : active, degraded
Active Devices : 22
Working Devices : 22
Failed Devices : 2
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Name : 00259009BA16:md0 (local to host 00259009BA16)
UUID : fca4c639:41713d3f:20fa02e3:89b64c95
Events : 36
Number Major Minor RaidDevice State
0 65 81 0 active sync /dev/sdv1
1 65 97 1 active sync /dev/sdw1
2 65 113 2 active sync /dev/sdx1
3 65 129 3 active sync /dev/sdy1
4 65 17 4 active sync /dev/sdr1
5 65 33 5 active sync /dev/sds1
6 65 49 6 active sync /dev/sdt1
7 65 65 7 active sync /dev/sdu1
8 8 145 8 active sync /dev/sdj1
9 8 161 9 active sync /dev/sdk1
10 8 177 10 active sync /dev/sdl1
11 8 193 11 active sync /dev/sdm1
12 8 225 12 active sync /dev/sdo1
13 8 241 13 active sync /dev/sdp1
14 65 1 14 active sync /dev/sdq1
23 8 81 15 faulty spare rebuilding
16 8 17 16 active sync /dev/sdb1
17 8 33 17 active sync /dev/sdc1
18 8 49 18 active sync /dev/sdd1
19 8 65 19 active sync /dev/sde1
20 8 97 20 active sync /dev/sdg1
21 8 113 21 active sync /dev/sdh1
22 8 129 22 active sync /dev/sdi1
15 8 209 - faulty spare
What surprised me though is that I was no longer able to run IO on the
md0 device. As a test, I am using fio to generate IO to the XFS
mountpoint /volumes/pool1/vol1. However, IO failed. A few minutes
later, I received the following kernel dumps in /var/log/messages. Any
ideas?
Jun 12 11:33:54 TESTBA16 kernel: [59435.936575] fio D
ffff88060c6e1a50 0 30463 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.936578] ffff880609887778
0000000000000086 0000000000000001 0000000000000086
Jun 12 11:33:54 TESTBA16 kernel: [59435.936581] 0000000000011e40
ffff88060c6e16c0 ffff88060c6e1a50 ffff880609887fd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.936583] ffff88060c6e1a58
0000000000011e40 ffff880609886010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.936586] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.936594] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936602] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.936607] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.936610] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.936615] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936617] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.936620] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.936622] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.936624] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.936629] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936631] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936633] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.936635] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.936637] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.936639] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936672] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936675] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.936690] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936706] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936710] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.936724] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936739] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936754] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936769] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936772] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936775] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.936777] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936779] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936781] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.936784] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.936789] fio D
ffff88060b063110 0 30464 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.936791] ffff8805f70a9778
0000000000000086 0000000000000001 0000000000000001
Jun 12 11:33:54 TESTBA16 kernel: [59435.936793] 0000000000011e40
ffff88060b062d80 ffff88060b063110 ffff8805f70a9fd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.936795] ffff88060b063118
0000000000011e40 ffff8805f70a8010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.936798] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.936800] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936803] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.936805] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.936807] [<ffffffff813e8d2d>]
? __map_bio+0xad/0x130
Jun 12 11:33:54 TESTBA16 kernel: [59435.936809] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.936811] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936813] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.936815] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.936817] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.936819] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.936821] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936823] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936825] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.936827] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.936829] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.936831] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936847] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936849] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.936864] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936879] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936882] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.936896] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936910] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936925] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936940] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936942] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936944] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.936946] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936948] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936950] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.936953] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.936957] fio D
ffff88060c679a50 0 30465 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.936959] ffff8805ad67f778
0000000000000086 0000000000000001 0000000000000086
Jun 12 11:33:54 TESTBA16 kernel: [59435.936961] 0000000000011e40
ffff88060c6796c0 ffff88060c679a50 ffff8805ad67ffd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.936964] ffff88060c679a58
0000000000011e40 ffff8805ad67e010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.936966] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.936968] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.936971] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.936973] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.936975] [<ffffffff813e8d2d>]
? __map_bio+0xad/0x130
Jun 12 11:33:54 TESTBA16 kernel: [59435.936977] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.936979] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936982] [<ffffffff8113bbf0>]
? __slab_alloc+0xb0/0x2c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936984] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.936986] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.936988] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.936990] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.936992] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936994] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.936996] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.936998] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.937000] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.937003] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937018] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937020] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.937035] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937050] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937053] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.937067] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937081] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937096] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937111] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937113] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937115] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.937117] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937119] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937121] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.937124] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.937128] fio D
ffff88060c525e90 0 30466 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937130] ffff8806099ab778
0000000000000082 ffff8806099ab748 0000000000000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937132] 0000000000011e40
ffff88060c525b00 ffff88060c525e90 ffff8806099abfd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.937134] ffff88060c525e98
0000000000011e40 ffff8806099aa010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937136] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.937139] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937142] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937144] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.937146] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.937148] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937150] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937152] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937154] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.937156] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.937158] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937160] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937162] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.937164] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.937166] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.937168] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937184] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937186] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.937201] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937216] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937219] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.937233] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937247] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937262] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937277] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937279] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937281] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.937283] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937285] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937287] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.937290] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.937294] fio D
ffff88060b488390 0 30467 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937296] ffff8805af683778
0000000000000086 0000000000000001 0000000000000086
Jun 12 11:33:54 TESTBA16 kernel: [59435.937298] 0000000000011e40
ffff88060b488000 ffff88060b488390 ffff8805af683fd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.937300] ffff88060b488398
0000000000011e40 ffff8805af682010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937303] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.937305] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937308] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937310] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.937312] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.937314] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937316] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937318] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937320] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.937322] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.937324] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937326] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937328] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.937330] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.937332] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.937334] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937350] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937352] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.937367] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937382] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937385] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.937399] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937413] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937428] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937443] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937445] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937447] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.937449] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937451] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937454] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.937456] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.937460] fio D
ffff880608b61a50 0 30468 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937462] ffff8805f77c1778
0000000000000082 0000000000000001 0000000000000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937464] 0000000000011e40
ffff880608b616c0 ffff880608b61a50 ffff8805f77c1fd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.937466] ffff880608b61a58
0000000000011e40 ffff8805f77c0010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937469] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.937471] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937474] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937476] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.937478] [<ffffffff813e8d2d>]
? __map_bio+0xad/0x130
Jun 12 11:33:54 TESTBA16 kernel: [59435.937480] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.937482] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937484] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937486] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937488] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.937490] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.937492] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937494] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937496] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.937498] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.937501] [<ffffffff81043b35>]
? find_busiest_group+0x65/0x340
Jun 12 11:33:54 TESTBA16 kernel: [59435.937503] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.937506] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937521] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937523] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.937538] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937553] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937556] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.937570] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937584] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937599] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937615] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937617] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937618] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.937620] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937622] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937625] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.937627] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.937631] fio D
ffff88060b1cc7d0 0 30469 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937634] ffff88060ba3f778
0000000000000086 0000000000000001 00000000ffffffff
Jun 12 11:33:54 TESTBA16 kernel: [59435.937636] 0000000000011e40
ffff88060b1cc440 ffff88060b1cc7d0 ffff88060ba3ffd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.937638] ffff88060b1cc7d8
0000000000011e40 ffff88060ba3e010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937640] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.937643] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937645] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937648] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.937650] [<ffffffff812789ae>]
? __make_request+0x41e/0x4b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937652] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.937654] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937656] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937658] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937660] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.937662] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.937664] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937666] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937668] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.937670] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.937672] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.937674] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937690] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937692] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.937707] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937722] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937725] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.937739] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937753] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937768] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937784] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937786] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937788] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.937789] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937792] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937794] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.937796] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.937800] fio D
ffff88060afe8390 0 30470 1 0x00000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937802] ffff8805f74c5778
0000000000000082 0000000000000001 00000000ffffffff
Jun 12 11:33:54 TESTBA16 kernel: [59435.937805] 0000000000011e40
ffff88060afe8000 ffff88060afe8390 ffff8805f74c5fd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.937807] ffff88060afe8398
0000000000011e40 ffff8805f74c4010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937809] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.937812] [<ffffffffa025e698>]
make_request+0x138/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937814] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937816] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.937818] [<ffffffff812786a0>]
? __make_request+0x110/0x4b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937820] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.937822] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937824] [<ffffffff8113bbf0>]
? __slab_alloc+0xb0/0x2c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937826] [<ffffffff813ea13b>]
? dm_get_live_table+0x4b/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937828] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.937830] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.937832] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.937834] [<ffffffff8118355c>]
dio_bio_submit+0xbc/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937836] [<ffffffff811835f5>]
dio_send_cur_page+0x95/0xc0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937838] [<ffffffff81183685>]
submit_page_section+0x65/0x170
Jun 12 11:33:54 TESTBA16 kernel: [59435.937840] [<ffffffff81183bb5>]
do_direct_IO+0x375/0x430
Jun 12 11:33:54 TESTBA16 kernel: [59435.937842] [<ffffffff81183ff4>]
direct_io_worker+0x1c4/0x390
Jun 12 11:33:54 TESTBA16 kernel: [59435.937845] [<ffffffff8118442d>]
__blockdev_direct_IO+0x26d/0x2d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937860] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937862] [<ffffffff81047893>]
? perf_event_task_sched_out+0x33/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.937877] [<ffffffffa05894af>]
xfs_vm_direct_IO+0x11f/0x130 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937893] [<ffffffffa0589a80>]
? xfs_get_blocks_direct+0x0/0x20 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937895] [<ffffffff810f6d95>]
generic_file_aio_read+0x215/0x230
Jun 12 11:33:54 TESTBA16 kernel: [59435.937909] [<ffffffffa0567cac>]
? xfs_ilock+0x6c/0xe0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937924] [<ffffffffa0567976>]
? xfs_ilock_demote+0x76/0xb0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937939] [<ffffffffa058fad1>]
xfs_file_aio_read+0x161/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937954] [<ffffffffa058f970>]
? xfs_file_aio_read+0x0/0x2d0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937956] [<ffffffff8118d48c>]
aio_rw_vect_retry+0x7c/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937958] [<ffffffff8118ee02>]
aio_run_iocb+0x62/0x190
Jun 12 11:33:54 TESTBA16 kernel: [59435.937960] [<ffffffff8118f8a0>]
io_submit_one+0x180/0x2f0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937962] [<ffffffff8118fb4c>]
do_io_submit+0x13c/0x2b0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937964] [<ffffffff8118fcd0>]
sys_io_submit+0x10/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.937966] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
Jun 12 11:33:54 TESTBA16 kernel: [59435.937970] fio D
ffff88060c4d3110 0 30764 1 0x00000004
Jun 12 11:33:54 TESTBA16 kernel: [59435.937973] ffff880609307898
0000000000000082 ffffffffffffffff 0000000000000000
Jun 12 11:33:54 TESTBA16 kernel: [59435.937975] 0000000000011e40
ffff88060c4d2d80 ffff88060c4d3110 ffff880609307fd8
Jun 12 11:33:54 TESTBA16 kernel: [59435.937977] ffff88060c4d3118
0000000000011e40 ffff880609306010 0000000000011e40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937979] Call Trace:
Jun 12 11:33:54 TESTBA16 kernel: [59435.937981] [<ffffffff813dfe85>]
md_write_start+0xb5/0x1e0
Jun 12 11:33:54 TESTBA16 kernel: [59435.937984] [<ffffffff81074d50>]
? autoremove_wake_function+0x0/0x40
Jun 12 11:33:54 TESTBA16 kernel: [59435.937987] [<ffffffffa025e5a1>]
make_request+0x41/0x3d0 [raid456]
Jun 12 11:33:54 TESTBA16 kernel: [59435.937989] [<ffffffff813da9b5>]
md_make_request+0xd5/0x210
Jun 12 11:33:54 TESTBA16 kernel: [59435.938004] [<ffffffffa0574ee9>]
? xlog_write+0x489/0x500 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938006] [<ffffffff813eab1f>]
? _dm_request+0x10f/0x160
Jun 12 11:33:54 TESTBA16 kernel: [59435.938008] [<ffffffff812760b8>]
generic_make_request+0x218/0x5c0
Jun 12 11:33:54 TESTBA16 kernel: [59435.938010] [<ffffffff813ed3d2>]
? linear_merge+0x52/0x60
Jun 12 11:33:54 TESTBA16 kernel: [59435.938012] [<ffffffff813ea7e1>]
? dm_merge_bvec+0xc1/0x140
Jun 12 11:33:54 TESTBA16 kernel: [59435.938014] [<ffffffff812764e6>]
submit_bio+0x86/0x110
Jun 12 11:33:54 TESTBA16 kernel: [59435.938030] [<ffffffffa058bca2>]
_xfs_buf_ioapply+0x192/0x2f0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938044] [<ffffffffa0571a8a>]
? xlog_bdstrat+0x2a/0x60 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938060] [<ffffffffa058dc61>]
xfs_buf_iorequest+0x51/0xd0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938074] [<ffffffffa0571a8a>]
xlog_bdstrat+0x2a/0x60 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938089] [<ffffffffa0573c18>]
xlog_sync+0x248/0x3f0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938104] [<ffffffffa0573e5b>]
xlog_state_release_iclog+0x9b/0xd0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938119] [<ffffffffa057481b>]
_xfs_log_force_lsn+0x1eb/0x290 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938135] [<ffffffffa0581f4d>]
_xfs_trans_commit+0x29d/0x2b0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938150] [<ffffffffa05885a5>]
xfs_change_file_space+0x1e5/0x2e0 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938154] [<ffffffff8115e0e1>]
? do_filp_open+0x181/0x770
Jun 12 11:33:54 TESTBA16 kernel: [59435.938170] [<ffffffffa058f14e>]
xfs_file_fallocate+0xde/0x150 [xfs]
Jun 12 11:33:54 TESTBA16 kernel: [59435.938172] [<ffffffff8115a515>]
? putname+0x35/0x50
Jun 12 11:33:54 TESTBA16 kernel: [59435.938174] [<ffffffff8115d50e>]
? do_unlinkat+0x5e/0x1d0
Jun 12 11:33:54 TESTBA16 kernel: [59435.938180] [<ffffffff812645a8>]
? apparmor_file_permission+0x18/0x20
Jun 12 11:33:54 TESTBA16 kernel: [59435.938183] [<ffffffff8114e1d3>]
do_fallocate+0x113/0x120
Jun 12 11:33:54 TESTBA16 kernel: [59435.938185] [<ffffffff8114e22e>]
sys_fallocate+0x4e/0x80
Jun 12 11:33:54 TESTBA16 kernel: [59435.938187] [<ffffffff810028ab>]
system_call_fastpath+0x16/0x1b
The errors seem to be a combination of XFS and md related messages.
Any insight into this issue would be greatly appreciated. Thanks!
-TG
--
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
* Re: Maximizing failed disk replacement on a RAID5 array
From: Durval Menezes @ 2011-06-13 5:32 UTC (permalink / raw)
To: Linux RAID
In-Reply-To: <BANLkTin8dpbxWfSCG_VoOM_FMmqCkm2mJg@mail.gmail.com>
Hello Folks,
On Wed, Jun 8, 2011 at 10:21 AM, Brad Campbell
<lists2009@fnarfbargle.com> wrote:
>
> Best of luck, and let us know how you get on.
Just finished the process here. To summarize, seems I've got my array
back in a stable state.
What I did:
1) Got a good backup of all the data in the array (using "tar") to
removable HDs, verified it (using md5sum), and then stored these
HDs safely offline;
2) Unmounted the filesystem in the array;
3) inserted the replacement disk on a USB dock, partitioned it,
then added it to the array ("mdadm --add");
-> Verified (via "mdadm --detail") that the replacement disk was
listed on the array as a "spare";
4) failed the bad disk in the array ("mdadm --fail")
-> At that point, the array immediatelly started to resync into the
replacement disk;
5) Monitored the resync process via "cat /proc/mdstat": it took
roughly 11 hours (I guess because transfer speed to the replacement
disk was limited by the USB ~40MB/s speed limit), but it signaled
no errors;
6) Verified that the array was really synced ("mdadm --detail") and
that there were indeed no errors during the resync (less
/var/log/messages);
7) removed the bad disk logically from the array ("mdadm --remove");
8) shut down the machine (init 0);
9) removed the bad disk physically from the machine, ejected the
replacement disk from the USB dock, and then installed the
replacement disk inside the machine;
10) turned the system on: the OS booted, assembled the array and
mounted the filesystem in it with no issues;
11) checked (using "md5sum -c" on the md5sum files generated during
pass#1 above) that all that ON THE ARRAY was indeed correct, so
in the end I didn't need to restore anything from backup.
Thanks for all the help, folks, and I pray we have the "hot-replace"
functionality implemented soon... it will make for much sounder sleep
the next time one of my disks fails... :-)
Cheers,
--
Durval Menezes.
--
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
* Re: Maximizing failed disk replacement on a RAID5 array
From: Durval Menezes @ 2011-06-13 5:56 UTC (permalink / raw)
To: Brad Campbell; +Cc: Brad Campbell, linux-raid, Drew
In-Reply-To: <4DEF2B59.7090408@fnarfbargle.com>
Hello Brad, folks,
On Wed, Jun 8, 2011 at 4:57 AM, Brad Campbell <lists2009@fnarfbargle.com> wrote:
> On 08/06/11 15:47, Durval Menezes wrote:
>
>> I'm sorry if I did not make myself clear; I've already run both a
>> "repair" on the RAID (see above) and a "smart -t long" on the
>> particular disk... I had about 40 bad sectors before, and now have
>> just 4, but these 4 sectors persist as being marked in error... I
>> think the "RAID repair" didn't touch them.
[...]
> I've never had md not report a repaired sector when performing a repair
> operation.
Just to keep you posted: after I finished replacing that failing disk,
I wrote zeroes to all its sectors (dd bs=16065b </dev/zero >/dev/DISK)
and then checked SMART again.
Guess what? As expected, the 4 sectors that were being reported in
both "Current_Pending_Sector" and "Offline_Uncorrectable" just went
away... both counters now report a big round "0".
So, it seems my hypothesis that these sectors were not being touched
by the md "repair" was indeed correct: once they were written to, they
ended up being automatically remapped (or at least cleaned out of the
above counters) by the HD firmware. Also, as the array resync reported
no errors whatsoever, it seems these sectors were simply not being
used by md.
Anyone has a good explanation to that? Inquiring minds want to know... :-)
Cheers,
--
Durval Menezes.
--
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
* [PATCH 1/3] md/raid5: fix raid5_set_bi_hw_segments
From: Namhyung Kim @ 2011-06-13 14:48 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid, linux-kernel
The @bio->bi_phys_segments consists of active stripes count in the
lower 16 bits and processed stripes count in the upper 16 bits. So
logical-OR operator should be bitwise one.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 346e69bfdab3..fa6ac70dc72f 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -129,7 +129,7 @@ static inline int raid5_dec_bi_hw_segments(struct bio *bio)
static inline void raid5_set_bi_hw_segments(struct bio *bio, unsigned int cnt)
{
- bio->bi_phys_segments = raid5_bi_phys_segments(bio) || (cnt << 16);
+ bio->bi_phys_segments = raid5_bi_phys_segments(bio) | (cnt << 16);
}
/* Find first data disk in a raid6 stripe */
--
1.7.5.2
^ permalink raw reply related
* [PATCH 2/3] md/raid5: fix FUA request handling in ops_run_io()
From: Namhyung Kim @ 2011-06-13 14:48 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid, linux-kernel, Tejun Heo
In-Reply-To: <1307976504-10215-1-git-send-email-namhyung@gmail.com>
Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support")
introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
However remaining code still checks whether rw is exactly same
as WRITE or not, so FUAed-write ends up with being treated as
READ. Fix it.
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index fa6ac70dc72f..026452bbb030 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -514,7 +514,7 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
bi = &sh->dev[i].req;
bi->bi_rw = rw;
- if (rw == WRITE)
+ if (rw & WRITE)
bi->bi_end_io = raid5_end_write_request;
else
bi->bi_end_io = raid5_end_read_request;
@@ -548,13 +548,13 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
bi->bi_io_vec[0].bv_offset = 0;
bi->bi_size = STRIPE_SIZE;
bi->bi_next = NULL;
- if (rw == WRITE &&
+ if (rw & WRITE &&
test_bit(R5_ReWrite, &sh->dev[i].flags))
atomic_add(STRIPE_SECTORS,
&rdev->corrected_errors);
generic_make_request(bi);
} else {
- if (rw == WRITE)
+ if (rw & WRITE)
set_bit(STRIPE_DEGRADED, &sh->state);
pr_debug("skip op %ld on disc %d for sector %llu\n",
bi->bi_rw, i, (unsigned long long)sh->sector);
--
1.7.5.2
^ permalink raw reply related
* [PATCH 3/3] md/raid5: remove unusual use of bio_iovec_idx()
From: Namhyung Kim @ 2011-06-13 14:48 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid, linux-kernel, Dan Williams
In-Reply-To: <1307976504-10215-1-git-send-email-namhyung@gmail.com>
In the bio_for_each_segment loop, bvl always points current
bio_vec, so the same as bio_iovec_idx(, i). Let's get rid of
it.
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 026452bbb030..0760716d0e3e 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -585,7 +585,7 @@ async_copy_data(int frombio, struct bio *bio, struct page *page,
init_async_submit(&submit, flags, tx, NULL, NULL, NULL);
bio_for_each_segment(bvl, bio, i) {
- int len = bio_iovec_idx(bio, i)->bv_len;
+ int len = bvl->bv_len;
int clen;
int b_offset = 0;
@@ -601,8 +601,8 @@ async_copy_data(int frombio, struct bio *bio, struct page *page,
clen = len;
if (clen > 0) {
- b_offset += bio_iovec_idx(bio, i)->bv_offset;
- bio_page = bio_iovec_idx(bio, i)->bv_page;
+ b_offset += bvl->bv_offset;
+ bio_page = bvl->bv_page;
if (frombio)
tx = async_memcpy(page, bio_page, page_offset,
b_offset, clen, &submit);
--
1.7.5.2
^ permalink raw reply related
* Re: HDD reports errors while completing RAID6 array check
From: Tim Blundell @ 2011-06-13 18:30 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <BANLkTimf-P1x57KmYbunGp8UHskvjQS35A@mail.gmail.com>
On 6/11/2011 5:49 AM, Mathias Burén wrote:
> === START OF INFORMATION SECTION ===
> Model Family: Western Digital Caviar Green (Adv. Format) family
> Device Model: WDC WD20EARS-00MVWB0
> Serial Number: WD-WMAZ20188479
> Firmware Version: 50.0AB50
> User Capacity: 2,000,398,934,016 bytes
> Device is: In smartctl database [for details use: -P show]
> ATA Version is: 8
> ATA Standard is: Exact ATA specification draft version not indicated
> Local Time is: Sat Jun 11 10:48:05 2011 IST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
Not certain if this was mentioned. While WDC WD20EARS drives can be used
in an RAID array, WD recommends using there RAID capable drives in an
enterprise environment.
I tried using same drives in a simple RAID-1 array and had serious
performance issues (sync taking a week) and stalls when writing to disk.
Are you using the stock firmware on these drives?
--
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
* Re: HDD reports errors while completing RAID6 array check
From: Mathias Burén @ 2011-06-13 18:41 UTC (permalink / raw)
To: Tim Blundell; +Cc: Linux-RAID
In-Reply-To: <4DF65758.2030405@gmail.com>
On 13 June 2011 19:30, Tim Blundell <tim.blundell@gmail.com> wrote:
>
> On 6/11/2011 5:49 AM, Mathias Burén wrote:
>>
>> === START OF INFORMATION SECTION ===
>> Model Family: Western Digital Caviar Green (Adv. Format) family
>> Device Model: WDC WD20EARS-00MVWB0
>> Serial Number: WD-WMAZ20188479
>> Firmware Version: 50.0AB50
>> User Capacity: 2,000,398,934,016 bytes
>> Device is: In smartctl database [for details use: -P show]
>> ATA Version is: 8
>> ATA Standard is: Exact ATA specification draft version not indicated
>> Local Time is: Sat Jun 11 10:48:05 2011 IST
>> SMART support is: Available - device has SMART capability.
>> SMART support is: Enabled
>
> Not certain if this was mentioned. While WDC WD20EARS drives can be used in
> an RAID array, WD recommends using there RAID capable drives in an
> enterprise environment.
> I tried using same drives in a simple RAID-1 array and had serious
> performance issues (sync taking a week) and stalls when writing to disk. Are
> you using the stock firmware on these drives?
>
> --
> 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
>
I'm using stock firmware as far as I know (I've not flashed them
manually), and I experience no performance issues. Of course, my
system is limited (RAID6 with an Intel Atom), so I can't really push
them all out to test it. But still, no issues.
/M
--
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
* Re: HDD reports errors while completing RAID6 array check
From: Brad Campbell @ 2011-06-14 0:15 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <4DF65758.2030405@gmail.com>
On 14/06/11 02:30, Tim Blundell wrote:
>
> On 6/11/2011 5:49 AM, Mathias Burén wrote:
>> === START OF INFORMATION SECTION ===
>> Model Family: Western Digital Caviar Green (Adv. Format) family
>> Device Model: WDC WD20EARS-00MVWB0
>> Serial Number: WD-WMAZ20188479
>> Firmware Version: 50.0AB50
>> User Capacity: 2,000,398,934,016 bytes
>> Device is: In smartctl database [for details use: -P show]
>> ATA Version is: 8
>> ATA Standard is: Exact ATA specification draft version not indicated
>> Local Time is: Sat Jun 11 10:48:05 2011 IST
>> SMART support is: Available - device has SMART capability.
>> SMART support is: Enabled
>
> Not certain if this was mentioned. While WDC WD20EARS drives can be used in an RAID array, WD
> recommends using there RAID capable drives in an enterprise environment.
> I tried using same drives in a simple RAID-1 array and had serious performance issues (sync taking
> a week) and stalls when writing to disk. Are you using the stock firmware on these drives?
Just a data point. I have 10 of them in a RAID-6. They are in a 6 core / 16GB box with PCIe SAS
controllers (so the machine is not bandwidth starved). I hammer the living daylights out of them.
They are quite fast for sequential access, not very fast for random IO and they are pretty cool and
quiet.
I have used WDIDLE3 to turn off the idle timer to stop the heads unloading though.
The reason WD state their consumer drives are no good in RAID applications is TLER. On a hardware
RAID controller the drives can get kicked out of the array if they go into a deep recovery read, but
md does not suffer this issue.
On SMART, it's prudent to configure smartmontools to do regular checks and e-mail you if it sees an
issue. I do a long every sunday and shorts every other morning and have had early notification of
pending issues a couple of times. Definitely worth the price of admission.
--
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
* Re: [PATCH 1/4] imsm: FIX: Cannot create volume
From: NeilBrown @ 2011-06-14 2:07 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110609162912.690.5879.stgit@gklab-128-013.igk.intel.com>
On Thu, 09 Jun 2011 18:29:12 +0200 Adam Kwolek <adam.kwolek@intel.com> wrote:
> getinfo_super_imsm_volume() clears entire 'info' structure before filling with new
> information. Disk number and raid_disk can be required later by caller
> but it is lost.
>
> Restore disk number information in getinfo_super_imsm_volume() call.
I need a better explanation than this.
When is getinfo_super_imsm or getinfo_super_imsm_volume *ever* called in a
situation where 'info' contains a meaningful value for disk.number???
I could not find it.
Alternately, explain what goes wrong with the current code (yes, I could
probably test it myself ... but if you send a patch you should justify it).
So for now this patch has not been applied.
Thanks,
NeilBrown
>
> Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
> ---
>
> super-intel.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index 5c840ec..e094b85 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -2075,11 +2075,18 @@ static void getinfo_super_imsm_volume(struct supertype *st, struct mdinfo *info,
> unsigned int component_size_alligment;
> int map_disks = info->array.raid_disks;
>
> - memset(info, 0, sizeof(*info));
> if (prev_map)
> map_to_analyse = prev_map;
>
> dl = super->disks;
> + while (dl) {
> + if (dl->index == info->disk.number)
> + break;
> + dl = dl->next;
> + }
> + if (!dl)
> + dl = super->disks;
> + memset(info, 0, sizeof(*info));
>
> info->container_member = super->current_vol;
> info->array.raid_disks = map->num_members;
> @@ -2147,6 +2154,8 @@ static void getinfo_super_imsm_volume(struct supertype *st, struct mdinfo *info,
> if (dl) {
> info->disk.major = dl->major;
> info->disk.minor = dl->minor;
> + info->disk.number = dl->index;
> + info->disk.raid_disk = dl->index;
> }
>
> info->data_offset = __le32_to_cpu(map_to_analyse->pba_of_lba0);
^ permalink raw reply
* Re: [PATCH 2/4] FIX: Cannot create volume
From: NeilBrown @ 2011-06-14 2:35 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110609162921.690.90444.stgit@gklab-128-013.igk.intel.com>
On Thu, 09 Jun 2011 18:29:21 +0200 Adam Kwolek <adam.kwolek@intel.com> wrote:
> getinfo_super() can clear entire 'inf' structure before filling with new
> information. Disk number required later is lost.
>
> Restore disk number information after getinfo_super() call.
>
> Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
> ---
>
> Create.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Create.c b/Create.c
> index 7b4d0fe..d01dea7 100644
> --- a/Create.c
> +++ b/Create.c
> @@ -805,7 +805,6 @@ int Create(struct supertype *st, char *mddev,
> switch(pass) {
> case 1:
> *inf = info;
> -
> inf->disk.number = dnum;
> inf->disk.raid_disk = dnum;
> if (inf->disk.raid_disk < raiddisks)
> @@ -856,12 +855,13 @@ int Create(struct supertype *st, char *mddev,
> /* getinfo_super might have lost these ... */
> inf->disk.major = major(stb.st_rdev);
> inf->disk.minor = minor(stb.st_rdev);
> + inf->disk.number = dnum;
> + inf->disk.raid_disk = dnum;
> }
> break;
> case 2:
> inf->errors = 0;
> rv = 0;
> -
> rv = add_disk(mdfd, st, &info, inf);
>
> if (rv) {
Unfortunately this is wrong too.
There should be no need to set disk.number and disk.raid_disk as the
->getinfo_super is supposed to have set them.
As the comment in mdadm.h says:
/* Extract generic details from metadata. This could be details about
* the container, or about an individual array within the container.
* The determination is made either by:
* load_super being given a 'component' string.
* validate_geometry determining what to create.
* The info includes both array information and device information.
* The particular device should be:
* The last device added by add_to_super
* The device the metadata was loaded from by load_super
* If 'map' is present, then it is an array raid_disks long
* (raid_disk must already be set and correct) and it is filled
* with 1 for slots that are thought to be active and 0 for slots which
* appear to be failed/missing.
* *info is zeroed out before data is added.
*/
In this case, ->add_to_super was recently called so it should record state so
that getinfo_super can return the correct information. That is what super0
and super1 does.
It seems that this has been wrong for a long time and my recent change to
zero the info structure showed it up.
So I'll let the patch through so as not to hold things up unnecessarily, but
I would really like you to see if you can fix add_to_super and getinfo_super
so that they follow the documented behaviour.
Thanks,
NeilBrown
^ permalink raw reply
* Re: [PATCH 2/2] imsm: FIX: klocwork: passed dev pointer to is_gen_migration() can be NULL
From: NeilBrown @ 2011-06-14 2:50 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110610155639.24539.67025.stgit@gklab-128-013.igk.intel.com>
On Fri, 10 Jun 2011 17:56:39 +0200 Adam Kwolek <adam.kwolek@intel.com> wrote:
> Pointer dev2 passed in write_super_imsm():4451 can be equal to NULL.
>
> Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
> ---
>
> super-intel.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index 8dd0805..3b4010d 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -5321,6 +5321,9 @@ static int update_subarray_imsm(struct supertype *st, char *subarray,
>
> static int is_gen_migration(struct imsm_dev *dev)
> {
> + if (dev == NULL)
> + return 0;
> +
> if (!dev->vol.migr_state)
> return 0;
>
Thanks. I have applied this and most of the others you sent.
NeilBrown
^ permalink raw reply
* Re: [PATCH/RFC] md/multipath: implement I/O balancing
From: NeilBrown @ 2011-06-14 3:59 UTC (permalink / raw)
To: Namhyung Kim; +Cc: linux-raid
In-Reply-To: <1307705531-26384-1-git-send-email-namhyung@gmail.com>
On Fri, 10 Jun 2011 20:32:11 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> Implement basic I/O balancing code (for read/write) for multipath
> personality. The code is based on RAID1 implementation.
Thanks, but no thanks.
As far as I am concerned, the md/multipath implementation is deprecated. The
dm-multipath implementation is much more mature and is more widely used and
actually has a sensible design - unlike md/multipath which has always had a
bad design.
I would rip it out and throw it away if I could, but I believe there are
people who use it so doing that is too difficult.
But I will not be adding feature to it at all.
Thanks,
NeilBrown
>
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
> ---
> drivers/md/multipath.c | 70 ++++++++++++++++++++++++++++++++++++++---------
> drivers/md/multipath.h | 1 +
> 2 files changed, 57 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/md/multipath.c b/drivers/md/multipath.c
> index 3535c23af288..83c4f5105705 100644
> --- a/drivers/md/multipath.c
> +++ b/drivers/md/multipath.c
> @@ -30,29 +30,58 @@
>
> #define NR_RESERVED_BUFS 32
>
> -
> -static int multipath_map (multipath_conf_t *conf)
> +/*
> + * This routine returns the disk from which the requested read should
> + * be done. There is a per-array 'next expected sequential IO' sector
> + * number - if this matches on the next IO then we use the last disk.
> + * There is also a per-disk 'last know head position' sector that is
> + * maintained from IRQ contexts, IO completion handlers update this
> + * position correctly. We pick the disk whose head is closest.
> + *
> + * Note that 'sector' argument is for original bio whereas 'head_position'
> + * is maintained for each rdev so we should take it into account when
> + * calculating the distance.
> + */
> +static int multipath_map(multipath_conf_t *conf, sector_t sector)
> {
> int i, disks = conf->raid_disks;
> -
> - /*
> - * Later we do read balancing on the read side
> - * now we use the first available disk.
> - */
> + int best_disk;
> + sector_t best_dist;
>
> rcu_read_lock();
> +retry:
> + best_disk = -1;
> + best_dist = MaxSector;
> +
> for (i = 0; i < disks; i++) {
> + int dist;
> mdk_rdev_t *rdev = rcu_dereference(conf->multipaths[i].rdev);
> + sector_t this_sector = sector;
> +
> if (rdev && test_bit(In_sync, &rdev->flags)) {
> - atomic_inc(&rdev->nr_pending);
> - rcu_read_unlock();
> - return i;
> + this_sector += rdev->data_offset;
> + dist = abs(this_sector - conf->multipaths[i].head_position);
> + if (dist < best_dist) {
> + best_dist = dist;
> + best_disk = i;
> + }
> }
> }
> +
> + if (best_disk == -1) {
> + printk(KERN_ERR "multipath_map(): no more operational IO paths?\n");
> + } else {
> + mdk_rdev_t *rdev;
> +
> + rdev = rcu_dereference(conf->multipaths[best_disk].rdev);
> + if (!rdev || !test_bit(In_sync, &rdev->flags))
> + goto retry;
> +
> + atomic_inc(&rdev->nr_pending);
> + }
> rcu_read_unlock();
>
> - printk(KERN_ERR "multipath_map(): no more operational IO paths?\n");
> - return (-1);
> + return best_disk;
> }
>
> static void multipath_reschedule_retry (struct multipath_bh *mp_bh)
> @@ -82,6 +111,17 @@ static void multipath_end_bh_io (struct multipath_bh *mp_bh, int err)
> mempool_free(mp_bh, conf->pool);
> }
>
> +/*
> + * Update disk head position estimator based on IRQ completion info.
> + */
> +static inline void update_head_pos(int disk, struct multipath_bh *mp_bh)
> +{
> + multipath_conf_t *conf = mp_bh->mddev->private;
> +
> + conf->multipaths[disk].head_position =
> + mp_bh->bio.bi_sector + (mp_bh->bio.bi_size >> 9);
> +}
> +
> static void multipath_end_request(struct bio *bio, int error)
> {
> int uptodate = test_bit(BIO_UPTODATE, &bio->bi_flags);
> @@ -89,6 +129,8 @@ static void multipath_end_request(struct bio *bio, int error)
> multipath_conf_t *conf = mp_bh->mddev->private;
> mdk_rdev_t *rdev = conf->multipaths[mp_bh->path].rdev;
>
> + update_head_pos(mp_bh->path, mp_bh);
> +
> if (uptodate)
> multipath_end_bh_io(mp_bh, 0);
> else if (!(bio->bi_rw & REQ_RAHEAD)) {
> @@ -122,7 +164,7 @@ static int multipath_make_request(mddev_t *mddev, struct bio * bio)
> mp_bh->master_bio = bio;
> mp_bh->mddev = mddev;
>
> - mp_bh->path = multipath_map(conf);
> + mp_bh->path = multipath_map(conf, bio->bi_sector);
> if (mp_bh->path < 0) {
> bio_endio(bio, -EIO);
> mempool_free(mp_bh, conf->pool);
> @@ -356,7 +398,7 @@ static void multipathd (mddev_t *mddev)
> bio = &mp_bh->bio;
> bio->bi_sector = mp_bh->master_bio->bi_sector;
>
> - if ((mp_bh->path = multipath_map (conf))<0) {
> + if ((mp_bh->path = multipath_map(conf, bio->bi_sector)) < 0) {
> printk(KERN_ALERT "multipath: %s: unrecoverable IO read"
> " error for block %llu\n",
> bdevname(bio->bi_bdev,b),
> diff --git a/drivers/md/multipath.h b/drivers/md/multipath.h
> index 3c5a45eb5f8a..060fe2aabd97 100644
> --- a/drivers/md/multipath.h
> +++ b/drivers/md/multipath.h
> @@ -3,6 +3,7 @@
>
> struct multipath_info {
> mdk_rdev_t *rdev;
> + sector_t head_position;
> };
>
> struct multipath_private_data {
^ permalink raw reply
* Re: [PATCH 1/3] md/raid5: fix raid5_set_bi_hw_segments
From: NeilBrown @ 2011-06-14 4:12 UTC (permalink / raw)
To: Namhyung Kim; +Cc: linux-raid, linux-kernel
In-Reply-To: <1307976504-10215-1-git-send-email-namhyung@gmail.com>
On Mon, 13 Jun 2011 23:48:22 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> The @bio->bi_phys_segments consists of active stripes count in the
> lower 16 bits and processed stripes count in the upper 16 bits. So
> logical-OR operator should be bitwise one.
>
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
> ---
> drivers/md/raid5.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 346e69bfdab3..fa6ac70dc72f 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -129,7 +129,7 @@ static inline int raid5_dec_bi_hw_segments(struct bio *bio)
>
> static inline void raid5_set_bi_hw_segments(struct bio *bio, unsigned int cnt)
> {
> - bio->bi_phys_segments = raid5_bi_phys_segments(bio) || (cnt << 16);
> + bio->bi_phys_segments = raid5_bi_phys_segments(bio) | (cnt << 16);
> }
>
> /* Find first data disk in a raid6 stripe */
Thanks for this and the other 2!!
I have added "Cc: stable@kernel.org" to the first two and applied them. I
expect to send them off to Linus later today.
Thanks,
NeilBrown
^ permalink raw reply
* RE: [PATCH 1/4] imsm: FIX: Cannot create volume
From: Kwolek, Adam @ 2011-06-14 9:21 UTC (permalink / raw)
To: NeilBrown
Cc: linux-raid@vger.kernel.org, Williams, Dan J, Ciechanowski, Ed,
Neubauer, Wojciech, Wojcik, Krzysztof
In-Reply-To: <20110614120704.54a58bbe@notabene.brown>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of NeilBrown
> Sent: Tuesday, June 14, 2011 4:07 AM
> To: Kwolek, Adam
> Cc: linux-raid@vger.kernel.org; Williams, Dan J; Ciechanowski, Ed;
> Neubauer, Wojciech
> Subject: Re: [PATCH 1/4] imsm: FIX: Cannot create volume
>
> On Thu, 09 Jun 2011 18:29:12 +0200 Adam Kwolek <adam.kwolek@intel.com>
> wrote:
>
> > getinfo_super_imsm_volume() clears entire 'info' structure before
> filling with new
> > information. Disk number and raid_disk can be required later by caller
> > but it is lost.
> >
> > Restore disk number information in getinfo_super_imsm_volume() call.
>
> I need a better explanation than this.
>
> When is getinfo_super_imsm or getinfo_super_imsm_volume *ever* called in
> a
> situation where 'info' contains a meaningful value for disk.number???
> I could not find it.
Is not a matter of meaningful value (it is ok), this is restore of cleared by memset() value only.
Function getinfo_super_imsm_volume() clears entire mdinfo structure now.
We should restore mdinfo->disk.raid_disk structure field information
Currently some information is set for first available disk in metadata, but it should be set to correct value.
Creation is made in 2 stages:
Pass 1: Collects disks in infos table (Create.c:789)
Pass 2: adds disks to md for array creation purposes (Create.c:873)
When during pass 1 inf->disk.raid_disk is not set correctly (or cleared /0/), during pass 2 it cannot be added by add_disk() correctly.
add_disk() thinks that all disks has to be configured for slot 0 (as it is 'clean' value),
disk.number is not important here (it is set to have identical values set in Create.c).
disk.raid_number is value that cannot be cleared by getinfo to have possibility for crresc slot number configuration.
Second patch, you partially applied (for Create.c) was some kind of "plan B" only.
Please let me know if this is clear enough for you.
BR
Adam
>
> Alternately, explain what goes wrong with the current code (yes, I could
> probably test it myself ... but if you send a patch you should justify
> it).
>
> So for now this patch has not been applied.
>
> Thanks,
> NeilBrown
>
>
> >
> > Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
> > ---
> >
> > super-intel.c | 11 ++++++++++-
> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/super-intel.c b/super-intel.c
> > index 5c840ec..e094b85 100644
> > --- a/super-intel.c
> > +++ b/super-intel.c
> > @@ -2075,11 +2075,18 @@ static void getinfo_super_imsm_volume(struct
> supertype *st, struct mdinfo *info,
> > unsigned int component_size_alligment;
> > int map_disks = info->array.raid_disks;
> >
> > - memset(info, 0, sizeof(*info));
> > if (prev_map)
> > map_to_analyse = prev_map;
> >
> > dl = super->disks;
> > + while (dl) {
> > + if (dl->index == info->disk.number)
> > + break;
> > + dl = dl->next;
> > + }
> > + if (!dl)
> > + dl = super->disks;
> > + memset(info, 0, sizeof(*info));
> >
> > info->container_member = super->current_vol;
> > info->array.raid_disks = map->num_members;
> > @@ -2147,6 +2154,8 @@ static void getinfo_super_imsm_volume(struct
> supertype *st, struct mdinfo *info,
> > if (dl) {
> > info->disk.major = dl->major;
> > info->disk.minor = dl->minor;
> > + info->disk.number = dl->index;
> > + info->disk.raid_disk = dl->index;
> > }
> >
> > info->data_offset = __le32_to_cpu(map_to_analyse->pba_of_lba0);
>
> --
> 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
* [PATCH] imsm: FIX: Sometimes reshape cannot be finished
From: Adam Kwolek @ 2011-06-14 12:56 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
When array size is not aligned to copy area, number of migration unit
is increased in init_migr_record_imsm():7665 to reshape whole array.
During calculation of last migration unit, this should be in mind also,
otherwise checkpoint (max-1) is always written and reshape
is never finished in mdadm.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
---
super-intel.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index 5dc8ca8..d525295 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -7788,20 +7788,30 @@ abort:
int save_checkpoint_imsm(struct supertype *st, struct mdinfo *info, int state)
{
struct intel_super *super = st->sb;
+ unsigned long long blocks_per_unit;
+
if (load_imsm_migr_rec(super, info) != 0) {
dprintf("imsm: ERROR: Cannot read migration record "
"for checkpoint save.\n");
return 1;
}
- if (__le32_to_cpu(super->migr_rec->blocks_per_unit) == 0) {
+ blocks_per_unit = __le32_to_cpu(super->migr_rec->blocks_per_unit);
+ if (blocks_per_unit == 0) {
dprintf("imsm: no migration in progress.\n");
return 2;
}
-
super->migr_rec->curr_migr_unit =
- __cpu_to_le32(info->reshape_progress /
- __le32_to_cpu(super->migr_rec->blocks_per_unit));
+ info->reshape_progress / blocks_per_unit;
+ /* check if array is alligned to copy area
+ * if it is not alligned, add one to current migration unit value
+ * this can happend on array reshape finish only
+ */
+ if (info->reshape_progress % blocks_per_unit)
+ super->migr_rec->curr_migr_unit++;
+ super->migr_rec->curr_migr_unit =
+ __cpu_to_le32(super->migr_rec->curr_migr_unit);
+
super->migr_rec->rec_status = __cpu_to_le32(state);
super->migr_rec->dest_1st_member_lba =
__cpu_to_le32((__le32_to_cpu(super->migr_rec->curr_migr_unit))
^ permalink raw reply related
* [PATCH] imsm: Metadata Attributes compatibility support
From: Krzysztof Wojcik @ 2011-06-14 13:59 UTC (permalink / raw)
To: neilb
Cc: linux-raid, wojciech.neubauer, adam.kwolek, dan.j.williams,
ed.ciechanowski
From: Adam Kwolek <adam.kwolek@intel.com>
IMSM's meta data contains Attributes field that contains information about
supported features.
To assembly an array mdadm has to support all features specified by attributes.
The patch introduces new attributes support and validation of the attribuses
during an array assembly.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
---
super-intel.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 137 insertions(+), 9 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index 3b4010d..e3e21e6 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -41,15 +41,47 @@
#define MAX_SIGNATURE_LENGTH 32
#define MAX_RAID_SERIAL_LEN 16
-#define MPB_ATTRIB_CHECKSUM_VERIFY __cpu_to_le32(0x80000000)
-#define MPB_ATTRIB_PM __cpu_to_le32(0x40000000)
-#define MPB_ATTRIB_2TB __cpu_to_le32(0x20000000)
-#define MPB_ATTRIB_RAID0 __cpu_to_le32(0x00000001)
-#define MPB_ATTRIB_RAID1 __cpu_to_le32(0x00000002)
-#define MPB_ATTRIB_RAID10 __cpu_to_le32(0x00000004)
-#define MPB_ATTRIB_RAID1E __cpu_to_le32(0x00000008)
-#define MPB_ATTRIB_RAID5 __cpu_to_le32(0x00000010)
-#define MPB_ATTRIB_RAIDCNG __cpu_to_le32(0x00000020)
+/* supports RAID0 */
+#define MPB_ATTRIB_RAID0 __cpu_to_le32(0x00000001)
+/* supports RAID1 */
+#define MPB_ATTRIB_RAID1 __cpu_to_le32(0x00000002)
+/* supports RAID10 */
+#define MPB_ATTRIB_RAID10 __cpu_to_le32(0x00000004)
+/* supports RAID1E */
+#define MPB_ATTRIB_RAID1E __cpu_to_le32(0x00000008)
+/* supports RAID5 */
+#define MPB_ATTRIB_RAID5 __cpu_to_le32(0x00000010)
+/* supports RAID CNG */
+#define MPB_ATTRIB_RAIDCNG __cpu_to_le32(0x00000020)
+/* supports expanded stripe sizes of 256K, 512K and 1MB */
+#define MPB_ATTRIB_EXP_STRIPE_SIZE __cpu_to_le32(0x00000040)
+
+/* The OROM Support RST Caching of Volumes */
+#define MPB_ATTRIB_NVM __cpu_to_le32(0x02000000)
+/* The OROM supports creating disks greater than 2TB */
+#define MPB_ATTRIB_2TB_DISK __cpu_to_le32(0x04000000)
+/* The OROM supports Bad Block Management */
+#define MPB_ATTRIB_BBM __cpu_to_le32(0x08000000)
+
+/* THe OROM Supports NVM Caching of Volumes */
+#define MPB_ATTRIB_NEVER_USE2 __cpu_to_le32(0x10000000)
+/* The OROM supports creating volumes greater than 2TB */
+#define MPB_ATTRIB_2TB __cpu_to_le32(0x20000000)
+/* originally for PMP, now it's wasted b/c. Never use this bit! */
+#define MPB_ATTRIB_NEVER_USE __cpu_to_le32(0x40000000)
+/* Verify MPB contents against checksum after reading MPB */
+#define MPB_ATTRIB_CHECKSUM_VERIFY __cpu_to_le32(0x80000000)
+
+/* Define all supported attributes that have to be accepted by mdadm
+ */
+#define MPB_ATTRIB_SUPPORTED MPB_ATTRIB_CHECKSUM_VERIFY | \
+ MPB_ATTRIB_2TB | \
+ MPB_ATTRIB_2TB_DISK | \
+ MPB_ATTRIB_RAID0 | \
+ MPB_ATTRIB_RAID1 | \
+ MPB_ATTRIB_RAID10 | \
+ MPB_ATTRIB_RAID5 | \
+ MPB_ATTRIB_EXP_STRIPE_SIZE
#define MPB_SECTOR_CNT 2210
#define IMSM_RESERVED_SECTORS 4096
@@ -1096,6 +1128,90 @@ void examine_migr_rec_imsm(struct intel_super *super)
}
}
+/*******************************************************************************
+ * function: imsm_check_attributes
+ * Description: Function checks if features represented by attributes flags
+ * are supported by mdadm.
+ * Parameters:
+ * attributes - Attributes read from metadata
+ * Returns:
+ * 0 - passed attributes contains unsupported features flags
+ * 1 - all features are supported
+ ******************************************************************************/
+static int imsm_check_attributes(__u32 attributes)
+{
+ int ret_val = 1;
+ __u32 not_supported = (MPB_ATTRIB_SUPPORTED)^0xffffffff;
+
+ not_supported &= attributes;
+ if (not_supported) {
+ fprintf(stderr, Name "(IMSM): Unsupported attributes : %x\n", not_supported);
+ if (not_supported & MPB_ATTRIB_CHECKSUM_VERIFY) {
+ dprintf("\t\tMPB_ATTRIB_CHECKSUM_VERIFY \n");
+ not_supported ^= MPB_ATTRIB_CHECKSUM_VERIFY;
+ }
+ if (not_supported & MPB_ATTRIB_2TB) {
+ dprintf("\t\tMPB_ATTRIB_2TB\n");
+ not_supported ^= MPB_ATTRIB_2TB;
+ }
+ if (not_supported & MPB_ATTRIB_RAID0) {
+ dprintf("\t\tMPB_ATTRIB_RAID0\n");
+ not_supported ^= MPB_ATTRIB_RAID0;
+ }
+ if (not_supported & MPB_ATTRIB_RAID1) {
+ dprintf("\t\tMPB_ATTRIB_RAID1\n");
+ not_supported ^= MPB_ATTRIB_RAID1;
+ }
+ if (not_supported & MPB_ATTRIB_RAID10) {
+ dprintf("\t\tMPB_ATTRIB_RAID10\n");
+ not_supported ^= MPB_ATTRIB_RAID10;
+ }
+ if (not_supported & MPB_ATTRIB_RAID1E) {
+ dprintf("\t\tMPB_ATTRIB_RAID1E\n");
+ not_supported ^= MPB_ATTRIB_RAID1E;
+ }
+ if (not_supported & MPB_ATTRIB_RAID5) {
+ dprintf("\t\tMPB_ATTRIB_RAID5\n");
+ not_supported ^= MPB_ATTRIB_RAID5;
+ }
+ if (not_supported & MPB_ATTRIB_RAIDCNG) {
+ dprintf("\t\tMPB_ATTRIB_RAIDCNG\n");
+ not_supported ^= MPB_ATTRIB_RAIDCNG;
+ }
+ if (not_supported & MPB_ATTRIB_BBM) {
+ dprintf("\t\tMPB_ATTRIB_BBM\n");
+ not_supported ^= MPB_ATTRIB_BBM;
+ }
+ if (not_supported & MPB_ATTRIB_CHECKSUM_VERIFY) {
+ dprintf("\t\tMPB_ATTRIB_CHECKSUM_VERIFY (== MPB_ATTRIB_LEGACY)\n");
+ not_supported ^= MPB_ATTRIB_CHECKSUM_VERIFY;
+ }
+ if (not_supported & MPB_ATTRIB_EXP_STRIPE_SIZE) {
+ dprintf("\t\tMPB_ATTRIB_EXP_STRIP_SIZE\n");
+ not_supported ^= MPB_ATTRIB_EXP_STRIPE_SIZE;
+ }
+ if (not_supported & MPB_ATTRIB_2TB_DISK) {
+ dprintf("\t\tMPB_ATTRIB_2TB_DISK\n");
+ not_supported ^= MPB_ATTRIB_2TB_DISK;
+ }
+ if (not_supported & MPB_ATTRIB_NEVER_USE2) {
+ dprintf("\t\tMPB_ATTRIB_NEVER_USE2\n");
+ not_supported ^= MPB_ATTRIB_NEVER_USE2;
+ }
+ if (not_supported & MPB_ATTRIB_NEVER_USE) {
+ dprintf("\t\tMPB_ATTRIB_NEVER_USE\n");
+ not_supported ^= MPB_ATTRIB_NEVER_USE;
+ }
+
+ if (not_supported)
+ dprintf(Name "(IMSM): Unknown attributes : %x\n", not_supported);
+
+ ret_val = 0;
+ }
+
+ return ret_val;
+}
+
static void getinfo_super_imsm(struct supertype *st, struct mdinfo *info, char *map);
static void examine_super_imsm(struct supertype *st, char *homehost)
@@ -1117,6 +1233,11 @@ static void examine_super_imsm(struct supertype *st, char *homehost)
printf(" Orig Family : %08x\n", __le32_to_cpu(mpb->orig_family_num));
printf(" Family : %08x\n", __le32_to_cpu(mpb->family_num));
printf(" Generation : %08x\n", __le32_to_cpu(mpb->generation_num));
+ printf(" Attributes : ");
+ if (imsm_check_attributes(mpb->attributes))
+ printf("All supported\n");
+ else
+ printf("not supported\n");
getinfo_super_imsm(st, &info, NULL);
fname_from_uuid(st, &info, nbuf, ':');
printf(" UUID : %s\n", nbuf + 5);
@@ -5405,6 +5526,13 @@ static struct mdinfo *container_content_imsm(struct supertype *st, char *subarra
struct dl *d;
int spare_disks = 0;
+ /* do not assemble arrays when not all attributes are supported */
+ if (imsm_check_attributes(mpb->attributes) == 0) {
+ fprintf(stderr, Name ": IMSM metadata loading not allowed "
+ "due to attributes incompatibility.\n");
+ return NULL;
+ }
+
/* check for bad blocks */
if (imsm_bbm_log_size(super->anchor))
bbm_errors = 1;
^ permalink raw reply related
* Re: [PATCH] imsm: FIX: Sometimes reshape cannot be finished
From: NeilBrown @ 2011-06-14 23:15 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110614125622.12762.4928.stgit@gklab-128-013.igk.intel.com>
On Tue, 14 Jun 2011 14:56:22 +0200 Adam Kwolek <adam.kwolek@intel.com> wrote:
> When array size is not aligned to copy area, number of migration unit
> is increased in init_migr_record_imsm():7665 to reshape whole array.
> During calculation of last migration unit, this should be in mind also,
> otherwise checkpoint (max-1) is always written and reshape
> is never finished in mdadm.
>
> Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
> ---
>
> super-intel.c | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index 5dc8ca8..d525295 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -7788,20 +7788,30 @@ abort:
> int save_checkpoint_imsm(struct supertype *st, struct mdinfo *info, int state)
> {
> struct intel_super *super = st->sb;
> + unsigned long long blocks_per_unit;
> +
> if (load_imsm_migr_rec(super, info) != 0) {
> dprintf("imsm: ERROR: Cannot read migration record "
> "for checkpoint save.\n");
> return 1;
> }
>
> - if (__le32_to_cpu(super->migr_rec->blocks_per_unit) == 0) {
> + blocks_per_unit = __le32_to_cpu(super->migr_rec->blocks_per_unit);
> + if (blocks_per_unit == 0) {
> dprintf("imsm: no migration in progress.\n");
> return 2;
> }
> -
> super->migr_rec->curr_migr_unit =
> - __cpu_to_le32(info->reshape_progress /
> - __le32_to_cpu(super->migr_rec->blocks_per_unit));
> + info->reshape_progress / blocks_per_unit;
> + /* check if array is alligned to copy area
> + * if it is not alligned, add one to current migration unit value
> + * this can happend on array reshape finish only
> + */
> + if (info->reshape_progress % blocks_per_unit)
> + super->migr_rec->curr_migr_unit++;
> + super->migr_rec->curr_migr_unit =
> + __cpu_to_le32(super->migr_rec->curr_migr_unit);
> +
> super->migr_rec->rec_status = __cpu_to_le32(state);
> super->migr_rec->dest_1st_member_lba =
> __cpu_to_le32((__le32_to_cpu(super->migr_rec->curr_migr_unit))
I think it is a bit untidy storing a value in cpu-order in super->migr_rec
and then changing it to little-endian later. It feels error prone.
So I have changed it to use a local variable for the cpu-order version as
below.
Thanks,
NeilBrown
commit f8b72ef517ea305f714230b0503f94ae5f1b8fa4
Author: Adam Kwolek <adam.kwolek@intel.com>
Date: Wed Jun 15 09:13:49 2011 +1000
imsm: FIX: Sometimes reshape cannot be finished
When array size is not aligned to copy area, number of migration unit
is increased in init_migr_record_imsm():7665 to reshape whole array.
During calculation of last migration unit, this should be in mind also,
otherwise checkpoint (max-1) is always written and reshape
is never finished in mdadm.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/super-intel.c b/super-intel.c
index 5dc8ca8..bb76f74 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -7788,24 +7788,34 @@ abort:
int save_checkpoint_imsm(struct supertype *st, struct mdinfo *info, int state)
{
struct intel_super *super = st->sb;
+ unsigned long long blocks_per_unit;
+ unsigned long long curr_migr_unit;
+
if (load_imsm_migr_rec(super, info) != 0) {
dprintf("imsm: ERROR: Cannot read migration record "
"for checkpoint save.\n");
return 1;
}
- if (__le32_to_cpu(super->migr_rec->blocks_per_unit) == 0) {
+ blocks_per_unit = __le32_to_cpu(super->migr_rec->blocks_per_unit);
+ if (blocks_per_unit == 0) {
dprintf("imsm: no migration in progress.\n");
return 2;
}
+ curr_migr_unit = info->reshape_progress / blocks_per_unit;
+ /* check if array is alligned to copy area
+ * if it is not alligned, add one to current migration unit value
+ * this can happend on array reshape finish only
+ */
+ if (info->reshape_progress % blocks_per_unit)
+ curr_migr_unit++;
super->migr_rec->curr_migr_unit =
- __cpu_to_le32(info->reshape_progress /
- __le32_to_cpu(super->migr_rec->blocks_per_unit));
+ __cpu_to_le32(curr_migr_unit);
super->migr_rec->rec_status = __cpu_to_le32(state);
super->migr_rec->dest_1st_member_lba =
- __cpu_to_le32((__le32_to_cpu(super->migr_rec->curr_migr_unit))
- * __le32_to_cpu(super->migr_rec->dest_depth_per_unit));
+ __cpu_to_le32(curr_migr_unit *
+ __le32_to_cpu(super->migr_rec->dest_depth_per_unit));
if (write_imsm_migr_rec(st) < 0) {
dprintf("imsm: Cannot write migration record "
"outside backup area\n");
^ permalink raw reply related
* Re: [PATCH] imsm: Metadata Attributes compatibility support
From: NeilBrown @ 2011-06-15 0:00 UTC (permalink / raw)
To: Krzysztof Wojcik
Cc: linux-raid, wojciech.neubauer, adam.kwolek, dan.j.williams,
ed.ciechanowski
In-Reply-To: <20110614135918.4994.26622.stgit@gklab-128-111.igk.intel.com>
On Tue, 14 Jun 2011 15:59:18 +0200 Krzysztof Wojcik
<krzysztof.wojcik@intel.com> wrote:
> From: Adam Kwolek <adam.kwolek@intel.com>
>
> IMSM's meta data contains Attributes field that contains information about
> supported features.
> To assembly an array mdadm has to support all features specified by attributes.
>
> The patch introduces new attributes support and validation of the attribuses
> during an array assembly.
Applied, thanks.
NeilBrown
>
> Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
> Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
> ---
> super-intel.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
> 1 files changed, 137 insertions(+), 9 deletions(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index 3b4010d..e3e21e6 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -41,15 +41,47 @@
> #define MAX_SIGNATURE_LENGTH 32
> #define MAX_RAID_SERIAL_LEN 16
>
> -#define MPB_ATTRIB_CHECKSUM_VERIFY __cpu_to_le32(0x80000000)
> -#define MPB_ATTRIB_PM __cpu_to_le32(0x40000000)
> -#define MPB_ATTRIB_2TB __cpu_to_le32(0x20000000)
> -#define MPB_ATTRIB_RAID0 __cpu_to_le32(0x00000001)
> -#define MPB_ATTRIB_RAID1 __cpu_to_le32(0x00000002)
> -#define MPB_ATTRIB_RAID10 __cpu_to_le32(0x00000004)
> -#define MPB_ATTRIB_RAID1E __cpu_to_le32(0x00000008)
> -#define MPB_ATTRIB_RAID5 __cpu_to_le32(0x00000010)
> -#define MPB_ATTRIB_RAIDCNG __cpu_to_le32(0x00000020)
> +/* supports RAID0 */
> +#define MPB_ATTRIB_RAID0 __cpu_to_le32(0x00000001)
> +/* supports RAID1 */
> +#define MPB_ATTRIB_RAID1 __cpu_to_le32(0x00000002)
> +/* supports RAID10 */
> +#define MPB_ATTRIB_RAID10 __cpu_to_le32(0x00000004)
> +/* supports RAID1E */
> +#define MPB_ATTRIB_RAID1E __cpu_to_le32(0x00000008)
> +/* supports RAID5 */
> +#define MPB_ATTRIB_RAID5 __cpu_to_le32(0x00000010)
> +/* supports RAID CNG */
> +#define MPB_ATTRIB_RAIDCNG __cpu_to_le32(0x00000020)
> +/* supports expanded stripe sizes of 256K, 512K and 1MB */
> +#define MPB_ATTRIB_EXP_STRIPE_SIZE __cpu_to_le32(0x00000040)
> +
> +/* The OROM Support RST Caching of Volumes */
> +#define MPB_ATTRIB_NVM __cpu_to_le32(0x02000000)
> +/* The OROM supports creating disks greater than 2TB */
> +#define MPB_ATTRIB_2TB_DISK __cpu_to_le32(0x04000000)
> +/* The OROM supports Bad Block Management */
> +#define MPB_ATTRIB_BBM __cpu_to_le32(0x08000000)
> +
> +/* THe OROM Supports NVM Caching of Volumes */
> +#define MPB_ATTRIB_NEVER_USE2 __cpu_to_le32(0x10000000)
> +/* The OROM supports creating volumes greater than 2TB */
> +#define MPB_ATTRIB_2TB __cpu_to_le32(0x20000000)
> +/* originally for PMP, now it's wasted b/c. Never use this bit! */
> +#define MPB_ATTRIB_NEVER_USE __cpu_to_le32(0x40000000)
> +/* Verify MPB contents against checksum after reading MPB */
> +#define MPB_ATTRIB_CHECKSUM_VERIFY __cpu_to_le32(0x80000000)
> +
> +/* Define all supported attributes that have to be accepted by mdadm
> + */
> +#define MPB_ATTRIB_SUPPORTED MPB_ATTRIB_CHECKSUM_VERIFY | \
> + MPB_ATTRIB_2TB | \
> + MPB_ATTRIB_2TB_DISK | \
> + MPB_ATTRIB_RAID0 | \
> + MPB_ATTRIB_RAID1 | \
> + MPB_ATTRIB_RAID10 | \
> + MPB_ATTRIB_RAID5 | \
> + MPB_ATTRIB_EXP_STRIPE_SIZE
>
> #define MPB_SECTOR_CNT 2210
> #define IMSM_RESERVED_SECTORS 4096
> @@ -1096,6 +1128,90 @@ void examine_migr_rec_imsm(struct intel_super *super)
> }
> }
>
> +/*******************************************************************************
> + * function: imsm_check_attributes
> + * Description: Function checks if features represented by attributes flags
> + * are supported by mdadm.
> + * Parameters:
> + * attributes - Attributes read from metadata
> + * Returns:
> + * 0 - passed attributes contains unsupported features flags
> + * 1 - all features are supported
> + ******************************************************************************/
> +static int imsm_check_attributes(__u32 attributes)
> +{
> + int ret_val = 1;
> + __u32 not_supported = (MPB_ATTRIB_SUPPORTED)^0xffffffff;
> +
> + not_supported &= attributes;
> + if (not_supported) {
> + fprintf(stderr, Name "(IMSM): Unsupported attributes : %x\n", not_supported);
> + if (not_supported & MPB_ATTRIB_CHECKSUM_VERIFY) {
> + dprintf("\t\tMPB_ATTRIB_CHECKSUM_VERIFY \n");
> + not_supported ^= MPB_ATTRIB_CHECKSUM_VERIFY;
> + }
> + if (not_supported & MPB_ATTRIB_2TB) {
> + dprintf("\t\tMPB_ATTRIB_2TB\n");
> + not_supported ^= MPB_ATTRIB_2TB;
> + }
> + if (not_supported & MPB_ATTRIB_RAID0) {
> + dprintf("\t\tMPB_ATTRIB_RAID0\n");
> + not_supported ^= MPB_ATTRIB_RAID0;
> + }
> + if (not_supported & MPB_ATTRIB_RAID1) {
> + dprintf("\t\tMPB_ATTRIB_RAID1\n");
> + not_supported ^= MPB_ATTRIB_RAID1;
> + }
> + if (not_supported & MPB_ATTRIB_RAID10) {
> + dprintf("\t\tMPB_ATTRIB_RAID10\n");
> + not_supported ^= MPB_ATTRIB_RAID10;
> + }
> + if (not_supported & MPB_ATTRIB_RAID1E) {
> + dprintf("\t\tMPB_ATTRIB_RAID1E\n");
> + not_supported ^= MPB_ATTRIB_RAID1E;
> + }
> + if (not_supported & MPB_ATTRIB_RAID5) {
> + dprintf("\t\tMPB_ATTRIB_RAID5\n");
> + not_supported ^= MPB_ATTRIB_RAID5;
> + }
> + if (not_supported & MPB_ATTRIB_RAIDCNG) {
> + dprintf("\t\tMPB_ATTRIB_RAIDCNG\n");
> + not_supported ^= MPB_ATTRIB_RAIDCNG;
> + }
> + if (not_supported & MPB_ATTRIB_BBM) {
> + dprintf("\t\tMPB_ATTRIB_BBM\n");
> + not_supported ^= MPB_ATTRIB_BBM;
> + }
> + if (not_supported & MPB_ATTRIB_CHECKSUM_VERIFY) {
> + dprintf("\t\tMPB_ATTRIB_CHECKSUM_VERIFY (== MPB_ATTRIB_LEGACY)\n");
> + not_supported ^= MPB_ATTRIB_CHECKSUM_VERIFY;
> + }
> + if (not_supported & MPB_ATTRIB_EXP_STRIPE_SIZE) {
> + dprintf("\t\tMPB_ATTRIB_EXP_STRIP_SIZE\n");
> + not_supported ^= MPB_ATTRIB_EXP_STRIPE_SIZE;
> + }
> + if (not_supported & MPB_ATTRIB_2TB_DISK) {
> + dprintf("\t\tMPB_ATTRIB_2TB_DISK\n");
> + not_supported ^= MPB_ATTRIB_2TB_DISK;
> + }
> + if (not_supported & MPB_ATTRIB_NEVER_USE2) {
> + dprintf("\t\tMPB_ATTRIB_NEVER_USE2\n");
> + not_supported ^= MPB_ATTRIB_NEVER_USE2;
> + }
> + if (not_supported & MPB_ATTRIB_NEVER_USE) {
> + dprintf("\t\tMPB_ATTRIB_NEVER_USE\n");
> + not_supported ^= MPB_ATTRIB_NEVER_USE;
> + }
> +
> + if (not_supported)
> + dprintf(Name "(IMSM): Unknown attributes : %x\n", not_supported);
> +
> + ret_val = 0;
> + }
> +
> + return ret_val;
> +}
> +
> static void getinfo_super_imsm(struct supertype *st, struct mdinfo *info, char *map);
>
> static void examine_super_imsm(struct supertype *st, char *homehost)
> @@ -1117,6 +1233,11 @@ static void examine_super_imsm(struct supertype *st, char *homehost)
> printf(" Orig Family : %08x\n", __le32_to_cpu(mpb->orig_family_num));
> printf(" Family : %08x\n", __le32_to_cpu(mpb->family_num));
> printf(" Generation : %08x\n", __le32_to_cpu(mpb->generation_num));
> + printf(" Attributes : ");
> + if (imsm_check_attributes(mpb->attributes))
> + printf("All supported\n");
> + else
> + printf("not supported\n");
> getinfo_super_imsm(st, &info, NULL);
> fname_from_uuid(st, &info, nbuf, ':');
> printf(" UUID : %s\n", nbuf + 5);
> @@ -5405,6 +5526,13 @@ static struct mdinfo *container_content_imsm(struct supertype *st, char *subarra
> struct dl *d;
> int spare_disks = 0;
>
> + /* do not assemble arrays when not all attributes are supported */
> + if (imsm_check_attributes(mpb->attributes) == 0) {
> + fprintf(stderr, Name ": IMSM metadata loading not allowed "
> + "due to attributes incompatibility.\n");
> + return NULL;
> + }
> +
> /* check for bad blocks */
> if (imsm_bbm_log_size(super->anchor))
> bbm_errors = 1;
^ permalink raw reply
* [PATCH RESEND 0/5] md/raid10 changes
From: Namhyung Kim @ 2011-06-15 2:01 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
Hello Neil,
This is a resend of my previous raid10 patches. Some of them are revised
according to your comments and some of them are not reviewed at all.
Please take a look.
Thanks.
Namhyung Kim (5):
md/raid10: optimize read_balance() for 'far offset' arrays
md/raid10: get rid of duplicated conditional expression
md/raid10: factor out common bio handling code
md/raid10: share pages between read and write bio's during recovery
md/raid10: spread read for subordinate r10bios during recovery
drivers/md/raid10.c | 83 +++++++++++++++++++++++++++-----------------------
1 files changed, 45 insertions(+), 38 deletions(-)
--
1.7.5.2
^ permalink raw reply
* [PATCH v2 1/5] md/raid10: optimize read_balance() for 'far offset' arrays
From: Namhyung Kim @ 2011-06-15 2:02 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308103324-2375-1-git-send-email-namhyung@gmail.com>
If @conf->far_offset > 0, there is only 1 stripe so that we can treat
the array same as 'near' arrays.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid10.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 6e846688962f..fc56bdd8c3fb 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -531,7 +531,7 @@ retry:
break;
/* for far > 1 always use the lowest address */
- if (conf->far_copies > 1)
+ if (conf->far_copies > 1 && conf->far_offset == 0)
new_distance = r10_bio->devs[slot].addr;
else
new_distance = abs(r10_bio->devs[slot].addr -
--
1.7.5.2
^ permalink raw reply related
* [PATCH 2/5] md/raid10: get rid of duplicated conditional expression
From: Namhyung Kim @ 2011-06-15 2:02 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308103324-2375-1-git-send-email-namhyung@gmail.com>
Variable 'first' is initialized to zero and updated to @rdev->raid_disk
only if it is greater than 0. Thus condition '>= first' always implies
'>= 0' so the latter is not needed.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid10.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index fc56bdd8c3fb..fcb86e86bc31 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1093,8 +1093,7 @@ static int raid10_add_disk(mddev_t *mddev, mdk_rdev_t *rdev)
if (rdev->raid_disk >= 0)
first = last = rdev->raid_disk;
- if (rdev->saved_raid_disk >= 0 &&
- rdev->saved_raid_disk >= first &&
+ if (rdev->saved_raid_disk >= first &&
conf->mirrors[rdev->saved_raid_disk].rdev == NULL)
mirror = rdev->saved_raid_disk;
else
--
1.7.5.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox