Linux RAID Storage Date Index

• Thread Index

• [PATCH 2/2] block: remove support for bio remapping from ->make_request
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [PATCH 1/2] block: export __make_request
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Kernel OOPs after RAID10 assemble
  • From: "Moshe Melnikov" <moshe@xxxxxxxxxxxxxxxxx>
• Kernel warning while read/writing
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: Converting RAID1 to RAID5
  • From: NeilBrown <neilb@xxxxxxx>
• Converting RAID1 to RAID5
  • From: Alex <mysqlstudent@xxxxxxxxx>
• RE: Bootable Raid-1
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• [PULL REQUEST] more md fixes for 3.1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Rotating RAID 1
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: Bootable Raid-1
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: Best strategy to incrementally replace smaller HDDs
  • From: Michał Sawicz <michal@xxxxxxxxxx>
• Re: Best strategy to incrementally replace smaller HDDs
  • From: Michał Sawicz <michal@xxxxxxxxxx>
• Re: [TuxOnIce-users] Repeatable md OOPS on suspend, 2.6.39.4 and 3.0.3
  • From: Nix <nix@xxxxxxxxxxxxx>
• Re: Best strategy to incrementally replace smaller HDDs
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: Best strategy to incrementally replace smaller HDDs
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Best strategy to incrementally replace smaller HDDs
  • From: Michał Sawicz <michal@xxxxxxxxxx>
• Re: Bootable Raid-1
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: Bootable Raid-1
  • From: hansbkk@xxxxxxxxx
• store a block device information in sb_info struct of ext4 file system
  • From: Shwety <shweta0232@xxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• RE: [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: "Dorau, Lukasz" <lukasz.dorau@xxxxxxxxx>
• [PATCH] udev rules: use $tempnode, check for supported types, comments
  • From: Michal Soltys <soltys@xxxxxxxx>
• v2 once more, for current head
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] kill-subarray: fix, cannot kill-subarray with unsupported metadata
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [mdadm PATCH] Fix small memory leak
  • From: NeilBrown <neilb@xxxxxxx>
• RE: [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: "Dorau, Lukasz" <lukasz.dorau@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• RE: [PATCH] Fix: Sometimes mdmon throws core dump during reshape
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• Re: Q: imsm rapid recovery volume
  • From: NeilBrown <neilb@xxxxxxx>
• RE: [PATCH] Fix: Sometimes mdmon throws core dump during reshape
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• Re: Q: imsm rapid recovery volume
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: [PATCH] kill-subarray: fix, cannot kill-subarray with unsupported metadata
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] util: fix seg-fault when trying to kill-subarray in a non-existing container
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] fix: segfault when killing subarray of non-existent container
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] Fix: Sometimes mdmon throws core dump during reshape
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 0/2] udev rules behaviour
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] mdadm: close parent file descriptors when starting mdmon.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] FIX: Prevent using null list pointer
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] FIX: Mdmon crashes after changing RAID level from 1 to 0
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Raid5 to another raid level??
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] trival: md_k.h should be md.h in the beginning comment of file md.h
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] util: fix seg-fault when trying to kill-subarray in a non-existing container
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• v2 - keep incremental, check types
  • From: Michal Soltys <soltys@xxxxxxxx>
• [PATCH] udev rules: add ddf, shorten checks, use $tempnode
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 5/9] imsm: fix reserved sectors for spares
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• Re: [PATCH] Fix: Sometimes mdmon throws core dump during reshape
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• Re: [PATCH] kill-subarray: fix, cannot kill-subarray with unsupported metadata
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• [PATCH] kill-subarray: fix, cannot kill-subarray with unsupported metadata
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [PATCH] util: fix seg-fault when trying to kill-subarray in a non-existing container
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: CoolCold <coolthecold@xxxxxxxxx>
• [PATCH] Fix: Sometimes mdmon throws core dump during reshape
  • From: Adam Kwolek <adam.kwolek@xxxxxxxxx>
• [PATCH 2/2] shorten remove rules
  • From: Michal Soltys <soltys@xxxxxxxx>
• [PATCH 0/2] udev rules behaviour
  • From: Michal Soltys <soltys@xxxxxxxx>
• [PATCH 1/2] udev rules: don't incrementally autoassemble everything
  • From: Michal Soltys <soltys@xxxxxxxx>
• [PATCH] trival: md_k.h should be md.h in the beginning comment of file md.h
  • From: Wang Sheng-Hui <shhuiw@xxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: Can reading a raid drive trigger all the other drives in that set?
  • From: Marc MERLIN <marc@xxxxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: [PATCH] FIX: Mdmon crashes after changing RAID level from 1 to 0
  • From: Jan Ceuleers <jan.ceuleers@xxxxxxxxxxxx>
• Re: Can reading a raid drive trigger all the other drives in that set?
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: Can reading a raid drive trigger all the other drives in that set?
  • From: Marc MERLIN <marc@xxxxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• [PATCH v2] mdadm: close parent file descriptors when starting mdmon.
  • From: Maciej Patelczyk <maciej.patelczyk@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: NeilBrown <neilb@xxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: NeilBrown <neilb@xxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• Re: Raid5 to another raid level??
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Raid5 to another raid level??
  • From: Michael Busby <michael.a.busby@xxxxxxxxx>
• Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Rudy Zijlstra <rudy@xxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: John Robinson <john.robinson@xxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Robin Hill <robin.hill47@xxxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: raid array with 3T disks and GPT partition
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• raid array with 3T disks and GPT partition
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• freshly grown array shrinks after first reboot - major data loss
  • From: Pim Zandbergen <P.Zandbergen@xxxxxxxxxxxxx>
• [PATCH] FIX: Prevent using null list pointer
  • From: Lukasz Dorau <lukasz.dorau@xxxxxxxxx>
• [PATCH] FIX: Cannot continue reshape if incremental assembly is used
  • From: Lukasz Dorau <lukasz.dorau@xxxxxxxxx>
• [PATCH] FIX: Mdmon crashes after changing RAID level from 1 to 0
  • From: Lukasz Dorau <lukasz.dorau@xxxxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: NeilBrown <neilb@xxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: dirty chunks on bitmap not clearing (RAID1)
  • From: Chris Pearson <pearson.christopher.j@xxxxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: Paul Clements <paul.clements@xxxxxxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: Paul Clements <paul.clements@xxxxxxxxxxx>
• Re: possible bug - bitmap dirty pages status
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: dirty chunks on bitmap not clearing (RAID1)
  • From: NeilBrown <neilb@xxxxxxx>
• [PULL REQUEST] md fixes for 3.1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: RAID5: failing an active component during spare rebuild - arrays hangs
  • From: NeilBrown <neilb@xxxxxxx>
• Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'
  • From: NeilBrown <neilb@xxxxxxx>
• Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• RE: [PATCH] mdadm: close parent file descriptors when starting mdmon.
  • From: "Patelczyk, Maciej" <maciej.patelczyk@xxxxxxxxx>
• Re: (solved) RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: [PATCH 9/9] mdadm: 'dump' support
  • From: Alexander Kühn <alexander.kuehn@xxxxxxxxxx>
• Re: [PATCH 0/9] recovering an imsm raid5 array
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 9/9] mdadm: 'dump' support
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 7/9] imsm: support 'missing' devices at Create
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 5/9] imsm: fix reserved sectors for spares
  • From: NeilBrown <neilb@xxxxxxx>
• Re: (solved) RAID1, changed disk, 2nd has errors ...
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: [PATCH] mdadm: close parent file descriptors when starting mdmon.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'
  • From: NeilBrown <neilb@xxxxxxx>
• MD devnode still present after 'remove' udev event, and mdadm reports 'does not appear to be active'
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: dirty chunks on bitmap not clearing (RAID1)
  • From: Chris Pearson <kermit4@xxxxxxxxx>
• [PATCH] mdadm: close parent file descriptors when starting mdmon.
  • From: Maciej Patelczyk <maciej.patelczyk@xxxxxxxxx>
• Re: (solved) RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: set sector or minimum write size?
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• set sector or minimum write size?
  • From: Chris Pearson <kermit4@xxxxxxxxx>
• possible bug - bitmap dirty pages status
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: Raid failing, which command to remove the bad drive?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Help - power failure during RAID6 grow
  • From: Michael-John Turner <mj@xxxxxxxxxxxx>
• Re: Help - power failure during RAID6 grow
  • From: NeilBrown <neilb@xxxxxxx>
• Raid failing, which command to remove the bad drive?
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: [PATCH 5/9] imsm: fix reserved sectors for spares
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• Re: Help - power failure during RAID6 grow
  • From: Michael-John Turner <mj@xxxxxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Help - power failure during RAID6 grow
  • From: Michael-John Turner <mj@xxxxxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: Robin Hill <robin.hill47@xxxxxxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: RAID1, changed disk, 2nd has errors ...
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• RAID1, changed disk, 2nd has errors ...
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: [PATCH 0/9] recovering an imsm raid5 array
  • From: linbloke <linbloke@xxxxxxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: linbloke <linbloke@xxxxxxxxxxx>
• [mdadm PATCH] Fix small memory leak
  • From: Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>
• [PATCH 9/9] mdadm: 'dump' support
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 8/9] util: allow regular files through test_partition()
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 7/9] imsm: support 'missing' devices at Create
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 6/9] mdmon: fix, close spare activation race
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 5/9] imsm: fix reserved sectors for spares
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 4/9] sysfs: fix sysfs_disk_to_scsi_id
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 3/9] imsm: fix display spares
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 2/9] imsm: fix, stop metadata updates to newly failed devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 1/9] imsm: fix max disks per array
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 0/9] recovering an imsm raid5 array
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• RE: Raid 5 to Raid 1 (half of the data not required)
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: Iwan Zarembo <iwan@xxxxxxxxxx>
• Re: RAID5: failing an active component during spare rebuild - arrays hangs
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: questions regarding few corner cases of mdadm usage
  • From: NeilBrown <neilb@xxxxxxx>
• Re: RAID5: failing an active component during spare rebuild - arrays hangs
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: maybe a raid10 module issue?
  • From: NeilBrown <neilb@xxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: NeilBrown <neilb@xxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: Iwan Zarembo <iwan@xxxxxxxxxx>
• Re: mixing backup with app serving on same box
  • From: Gordon Henderson <gordon@xxxxxxxxxx>
• Re: mixing backup with app serving on same box
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• mixing backup with app serving on same box
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: Raid 5 to Raid 1 (half of the data not required)
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Raid 5 to Raid 1 (half of the data not required)
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Raid 5 to Raid 1 (half of the data not required)
  • From: Gordon Henderson <gordon@xxxxxxxxxx>
• Re: Raid 5 to Raid 1 (half of the data not required)
  • From: Robin Hill <robin.hill47@xxxxxxxxxxxx>
• Re: Raid 5 to Raid 1 (half of the data not required)
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: Raid 5 to Raid 1 (half of the data not required)
  • From: NeilBrown <neilb@xxxxxxx>
• Raid 5 to Raid 1 (half of the data not required)
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: RAID10 failed with two disks
  • From: Piotr Legiecki <piotrlg@xxxxxxxxxx>
• Re: Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: external bitmaps on block devices?
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Rotating RAID 1
  • From: NeilBrown <neilb@xxxxxxx>
• external bitmaps on block devices?
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: [PATCH] md.4: two typos fixed
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: RAID10 failed with two disks
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] md.4: two typos fixed
  • From: NeilBrown <neilb@xxxxxxx>
• [PATCH] md.4: two typos fixed
  • From: Bill Allaire <vger@xxxxxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: RAID10 failed with two disks
  • From: Piotr Legiecki <piotrlg@xxxxxxxxxx>
• Re: RAID10 failed with two disks
  • From: NeilBrown <neilb@xxxxxxx>
• Re: RAID10 failed with two disks
  • From: Piotr Legiecki <piotrlg@xxxxxxxxxx>
• Re: RAID10 failed with two disks
  • From: NeilBrown <neilb@xxxxxxx>
• RAID10 failed with two disks
  • From: Piotr Legiecki <piotrlg@xxxxxxxxxx>
• Re: Device utilization with RAID-1
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: Iwan Zarembo <iwan@xxxxxxxxxx>
• Re: Device utilization with RAID-1
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: Device utilization with RAID-1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Device utilization with RAID-1
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: Device utilization with RAID-1
  • From: Stefan /*St0fF*/ Hübner <st0ff@xxxxxxx>
• Re: Device utilization with RAID-1
  • From: NeilBrown <neilb@xxxxxxx>
• Fwd: Re: Device utilization with RAID-1
  • From: Harald Nikolisin <hochglanz@xxxxxxxxx>
• Several problems with RAID-5 array
  • From: John Obaterspok <john.obaterspok@xxxxxxxxx>
• Re: First raid1 sector gets zeroed at first reboot
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: First raid1 sector gets zeroed at first reboot
  • From: Asdo <asdo@xxxxxxxxxxxxx>
• Re: First raid1 sector gets zeroed at first reboot
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: First raid1 sector gets zeroed at first reboot
  • From: Asdo <asdo@xxxxxxxxxxxxx>
• Re: First raid1 sector gets zeroed at first reboot
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: Daniel Frey <djqfrey@xxxxxxxxx>
• Re: IMSM Raid 5 always read only and gone after reboot
  • From: Daniel Frey <djqfrey@xxxxxxxxx>
• IMSM Raid 5 always read only and gone after reboot
  • From: Iwan Zarembo <iwan@xxxxxxxxxx>
• First raid1 sector gets zeroed at first reboot
  • From: Asdo <asdo@xxxxxxxxxxxxx>
• Re: Device utilization with RAID-1
  • From: Harald Nikolisin <hochglanz@xxxxxxxxx>
• Re: Rotating RAID 1
  • From: Pavel Hofman <pavel.hofman@xxxxxxxxxxx>
• Re: Rotating RAID 1
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: Device utilization with RAID-1
  • From: Roberto Spadim <roberto@xxxxxxxxxxxxx>
• Device utilization with RAID-1
  • From: Harald Nikolisin <hochglanz@xxxxxxxxx>
• Re: Rotating RAID 1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: Rotating RAID 1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Rotating RAID 1
  • From: Pavel Hofman <pavel.hofman@xxxxxxxxxxx>
• Re: Rotating RAID 1
  • From: Pavel Hofman <pavel.hofman@xxxxxxxxxxx>
• Re: Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: Rotating RAID 1
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Rotating RAID 1
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: latest version of mdadm for RedHat 5.3
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Asdo <asdo@xxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Asdo <asdo@xxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: mark delfman <markdelfman@xxxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: Couldn't remove rebuilding drive from RAID5 rebuild, now can't add new drive to array?
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] pnfs: Automatically select blocks & objects layouts
  • From: Peng Tao <bergwolf@xxxxxxxxx>
• Re: [PATCH] pnfs: Automatically select blocks & objects layouts
  • From: Jim Rees <rees@xxxxxxxxx>
• Re: Couldn't remove rebuilding drive from RAID5 rebuild, now can't add new drive to array?
  • From: Another Sillyname <anothersname@xxxxxxxxxxxxxx>
• Re: [PATCH v2] pnfs: Automatically select blocks & objects layouts
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [PATCH v2] pnfs: Automatically select blocks & objects layouts
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• [PATCH v2] pnfs: Automatically select blocks & objects layouts
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• [PATCH] pnfs: Automatically select blocks & objects layouts
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: latest version of mdadm for RedHat 5.3
  • From: NeilBrown <neilb@xxxxxxx>
• Re: single cpu thread performance limit?
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Joe Landman <joe.landman@xxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: mark delfman <markdelfman@xxxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Bernd Schubert <bernd.schubert@xxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: mark delfman <markdelfman@xxxxxxxxxxxxxx>
• Re: single cpu thread performance limit?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: latest version of mdadm for RedHat 5.3
  • From: John Papa <John.Papa@xxxxxxxxxx>
• single cpu thread performance limit?
  • From: mark delfman <markdelfman@xxxxxxxxxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• Couldn't remove rebuilding drive from RAID5 rebuild, now can't add new drive to array?
  • From: Another Sillyname <anothersname@xxxxxxxxxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Benny Halevy <bhalevy@xxxxxxxxxx>
• RE: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: <tao.peng@xxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• RE: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: <tao.peng@xxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Peng Tao <bergwolf@xxxxxxxxx>
• Re: Linux 3.1-rc1 (nfs/pnfs and drivers/md)
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• Re: mdadm(IMSM): Unsupported attributes : 40000000
  • From: Thomas Steinborn <thestonewell@xxxxxxxxxxxxxx>
• Re: mdadm forces resync every boot
  • From: NeilBrown <neilb@xxxxxxx>
• Re: mdadm forces resync every boot
  • From: Daniel Frey <djqfrey@xxxxxxxxx>
• questions regarding few corner cases of mdadm usage
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: mdadm forces resync every boot
  • From: Daniel Frey <djqfrey@xxxxxxxxx>
• RE: Need help recovering RAID5 array
  • From: "Muskiewicz, Stephen C" <Stephen_Muskiewicz@xxxxxxx>
• Re: Need help recovering RAID5 array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Undestanding /proc/mdstat with raid10
  • From: Torbjørn Skagestad <torbjorn@xxxxxxxx>
• RE: mdadm(IMSM): Unsupported attributes : 40000000
  • From: "Wojcik, Krzysztof" <krzysztof.wojcik@xxxxxxxxx>
• Undestanding /proc/mdstat with raid10
  • From: Sebastian Muniz <sjmuniz@xxxxxxxxx>
• Re: Need help recovering RAID5 array
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Need help recovering RAID5 array
  • From: Stephen Muskiewicz <stephen_muskiewicz@xxxxxxx>
• Re: [PATCH] RAID-6 check standalone man page
  • From: NeilBrown <neilb@xxxxxxx>
• Re: mdadm forces resync every boot
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Need help recovering RAID5 array
  • From: NeilBrown <neilb@xxxxxxx>
• Re: RAID6 check found different events, how should I proceed?
  • From: NeilBrown <neilb@xxxxxxx>
• Re: mdadm(IMSM): Unsupported attributes : 40000000
  • From: NeilBrown <neilb@xxxxxxx>
• RE: Need help recovering RAID5 array
  • From: "Muskiewicz, Stephen C" <Stephen_Muskiewicz@xxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Joe Landman <joe.landman@xxxxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Joe Landman <joe.landman@xxxxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Joe Landman <joe.landman@xxxxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxxx>
• Re: 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: NeilBrown <neilb@xxxxxxx>
• 20 drive raid-10, CentOS5.5, after reboot assemble fails - all drives "non-fresh"
  • From: Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxxx>
• [PATCH] RAID-6 check standalone man page
  • From: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
• Re: mdadm forces resync every boot
  • From: Daniel Frey <djqfrey@xxxxxxxxx>
• mdadm(IMSM): Unsupported attributes : 40000000
  • From: Thomas Steinborn <thestonewell@xxxxxxxxxxxxxx>
• Re: RAID6 check found different events, how should I proceed?
  • From: Alexander Kühn <alexander.kuehn@xxxxxxxxxx>
• Re: RAID6 check found different events, how should I proceed?
  • From: "Cal Leeming [Simplicity Media Ltd]" <cal.leeming@xxxxxxxxxxxxxxxxxxxxxxxx>
• Re: RAID6 check found different events, how should I proceed?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• RAID6 check found different events, how should I proceed?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: mdadm forces resync every boot
  • From: Erwan Leroux <erwan.lerou@xxxxxxxxx>
• Re: LUKS superblock damaged by `mdadm --create` or user error?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Need help recovering RAID5 array
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] fix: segfault when killing subarray of non-existent container
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Need help recovering RAID5 array
  • From: Stephen Muskiewicz <stephen_muskiewicz@xxxxxxx>
• mdadm forces resync every boot
  • From: Daniel Frey <djqfrey@xxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Re: LUKS superblock damaged by `mdadm --create` or user error?
  • From: Paul Menzel <pm.debian@xxxxxxxxxxxxxx>
• LUKS superblock damaged by `mdadm --create` or user error?
  • From: Paul Menzel <pm.debian@xxxxxxxxxxxxxx>
• Re: [PATCH] md: use REQ_NOIDLE flag in md_super_write()
  • From: NeilBrown <neilb@xxxxxxx>
• [PATCH] md/raid5: STRIPE_ACTIVE has lock semantics, add barriers
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH] md: use REQ_NOIDLE flag in md_super_write()
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: Mdadm re-add fails
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Mdadm re-add fails
  • From: Jan Vejvalka <jan.vejvalka@xxxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] md/raid1: factor out common bio handling code
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• [PATCH] md/raid1: factor out common bio handling code
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: Grub-install, superblock corrupted/erased and other animals
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Assembling array with missing members
  • From: Alex <mysqlstudent@xxxxxxxxx>
• Re: component device mismatches found: 9600
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: component device mismatches found: 9600
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: component device mismatches found: 9600
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: component device mismatches found: 9600
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• [PATCH] fix: segfault when killing subarray of non-existent container
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: Assembling array with missing members
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Assembling array with missing members
  • From: Alex <mysqlstudent@xxxxxxxxx>
• Re: Assembling array with missing members
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Assembling array with missing members
  • From: Alex <mysqlstudent@xxxxxxxxx>
• Re: linux-next: build warnings after merge of the moduleh tree
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: component device mismatches found: 9600
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Johannes Truschnigg <johannes@xxxxxxxxxxxxxxx>
• component device mismatches found: 9600
  • From: "Timothy D. Lenz" <tlenz@xxxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Do I have a bad HDD?
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: linux-next: build warnings after merge of the moduleh tree
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: upgrading the superblock version
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: data scrubbing
  • From: Beolach <beolach@xxxxxxxxx>
• Re: data scrubbing
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: data scrubbing
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: data scrubbing
  • From: Beolach <beolach@xxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Xavier Brochard <xavier@xxxxxxxxxxxxxx>
• Re: data scrubbing
  • From: Thomas Harold <thomas-lists@xxxxxxxxxx>
• Failures Rates Using SSD
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Roberto Spadim <roberto@xxxxxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• RE: RE: RAID5/6 Offload via IOATDMA
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: data scrubbing
  • From: Nikolay Kichukov <hijacker@xxxxxxxxx>
• Re: data scrubbing
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• data scrubbing
  • From: Nikolay Kichukov <hijacker@xxxxxxxxx>
• linux-next: build warnings after merge of the moduleh tree
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: RE: RAID5/6 Offload via IOATDMA
  • From: Errol Neal <eneal@xxxxxxxxxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Xavier Brochard <xavier@xxxxxxxxxxxxxx>
• RE: RAID5/6 Offload via IOATDMA
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• RAID5/6 Offload via IOATDMA
  • From: Errol Neal <eneal@xxxxxxxxxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: [md PATCH 16/36] md/raid1: factor several functions out or raid1d()
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: NeilBrown <neilb@xxxxxxx>
• [Patch mdadm-3.2.2] Fix readding of a readwrite drive into a writemostly array
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• [Patch mdadm-3.2.2] Fix the fix for the readd bug
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: [md PATCH 16/36] md/raid1: factor several functions out or raid1d()
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 15/36] md/raid1: improve handling of read failure during recovery.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 14/36] md/raid1: record badblocks found during resync etc.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 13/36] md/raid1: Handle write errors by updating badblock log.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 12/36] md/raid1: store behind-write pages in bi_vecs.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Joe Landman <joe.landman@xxxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: Lutz Vieweg <lvml@xxxxxx>
• Grub-install, superblock corrupted/erased and other animals
  • From: Aaron Scheiner <blue@xxxxxxxxxxxxxx>
• Re: [patch] md/raid10: double lock typo in handle_read_error()
  • From: NeilBrown <neilb@xxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• [patch] md/raid10: double lock typo in handle_read_error()
  • From: Dan Carpenter <error27@xxxxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: keld@xxxxxxxxxx
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Using the new bad-block-log in md for Linux 3.1
  • From: keld@xxxxxxxxxx
• Re: standard performance (write speed 20Mb/s)
  • From: Roman Mamedov <rm@xxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: [md PATCH 11/36] md/raid1: clear bad-block record when write succeeds.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 10/36] md/raid1: avoid writing to known-bad blocks on known-bad drives.
  • From: NeilBrown <neilb@xxxxxxx>
• Using the new bad-block-log in md for Linux 3.1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 10/36] md/raid1: avoid writing to known-bad blocks on known-bad drives.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 09/36] md: make it easier to wait for bad blocks to be acknowledged.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 02/36] md/bad-block-log: add sysfs interface for accessing bad-block-log.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Repairing a Raid-6 array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Repairing a Raid-6 array
  • From: Lemur Kryptering <gottail@xxxxxxxxxxxxx>
• Re: [md PATCH 09/36] md: make it easier to wait for bad blocks to be acknowledged.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 08/36] md: add 'write_error' flag to component devices.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• [PATCH v2] md: add documentation for bad block log
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: [md PATCH 07/36] md/raid1: avoid reading known bad blocks during resync
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 06/36] md/raid1: avoid reading from known bad blocks.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• Re: [md PATCH 02/36] md/bad-block-log: add sysfs interface for accessing bad-block-log.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] RAID-6 check standalone suspend array V2.0
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 02/36] md/bad-block-log: add sysfs interface for accessing bad-block-log.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 01/36] md: beginnings of bad block management.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 20/34] md/raid5: finalise new merged handle_stripe.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] Grow: fix version number in error message
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 01/36] md: beginnings of bad block management.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [md PATCH 02/36] md/bad-block-log: add sysfs interface for accessing bad-block-log.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 01/36] md: beginnings of bad block management.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 20/34] md/raid5: finalise new merged handle_stripe.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 19/34] md/raid5: move some more common code into handle_stripe
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 14/34] md/raid5: move more code into common handle_stripe
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 13/34] md/raid5: Move code for finishing a reconstruction into handle_stripe.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 11/34] md/raid5: add some more fields to stripe_head_state
  • From: NeilBrown <neilb@xxxxxxx>
• RAID5/6 Offload
  • From: Errol Neal <eneal@xxxxxxxxxxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: [PATCH] RAID-6 check standalone suspend array V2.0
  • From: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
• Re: [RFC PATCH 4/4] btrfs: Moved repair code from inode.c to extent_io.c
  • From: Jan Schmidt <list.btrfs@xxxxxxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Nikolay Kichukov <hijacker@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Paweł Brodacki <pawel.brodacki@xxxxxxxxxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: Vasco Névoa <vasco.nevoa@xxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: [md PATCH 05/36] md: Disable bad blocks and v0.90 metadata.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 01/36] md: beginnings of bad block management.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 04/36] md: load/store badblock list from v1.x metadata
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [dm-devel] [PATCH -next] dm: fix dm-flakey printk warning
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [md PATCH 03/36] md: don't allow arrays to contain devices with bad blocks.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 02/36] md/bad-block-log: add sysfs interface for accessing bad-block-log.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 01/36] md: beginnings of bad block management.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: standard performance (write speed 65Mb/s)
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: [md PATCH 20/34] md/raid5: finalise new merged handle_stripe.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 19/34] md/raid5: move some more common code into handle_stripe
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 18/34] md/raid5: move more common code into handle_stripe
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 16/34] md/raid5: unite fetch_block5 and fetch_block6
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: standard performance (write speed ??Mb/s) - new raid5 array
  • From: Erwan Leroux <erwan.lerou@xxxxxxxxx>
• Re: [md PATCH 15/34] md/raid5: rearrange a test in fetch_block6.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 14/34] md/raid5: move more code into common handle_stripe
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: [md PATCH 13/34] md/raid5: Move code for finishing a reconstruction into handle_stripe.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: standard performance (write speed ??Mb/s) - new raid5 array
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: [PATCH] RAID-6 check standalone suspend array V2.0
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 12/34] md/raid5: move stripe_head_state and more code into handle_stripe.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 11/34] md/raid5: add some more fields to stripe_head_state
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: NeilBrown <neilb@xxxxxxx>
• [PATCH 1/1] md: style/readability cleanups
  • From: Calvin Owens <jcalvinowens@xxxxxxxxx>
• Re: [md PATCH 09/34] md/raid5: move common code into handle_stripe
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 07/34] md/raid5: Protect some more code with ->device_lock.
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [md PATCH 06/34] md/raid5: Remove use of sh->lock in sync_request
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Tanguy Herrmann <dolanor@xxxxxxxxx>
• Re: [dm-devel] linux-next: Tree for July 21 (drivers/md/dm-raid)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: standard performance (write speed 65Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: standard performance (write speed ??Mb/s) - new raid5 array
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• [PATCH -next] dm: fix dm-flakey printk warning
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• Re: linux-next: Tree for July 21 (drivers/md/dm-raid)
  • From: NeilBrown <neilb@xxxxxxx>
• Re: linux-next: Tree for July 21 (drivers/md/dm-raid)
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• Re: standard performance (write speed 65Mb/s)
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: standard performance (write speed ??Mb/s) - new raid5 array
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: upgrading the superblock version
  • From: Vasco Névoa <vasco.nevoa@xxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Erwan Leroux <erwan.lerou@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Erwan Leroux <erwan.lerou@xxxxxxxxx>
• Re: Raid5 boot failure after grow
  • From: Shaun Reich <predator106@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Paweł Brodacki <pawel.brodacki@xxxxxxxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: mdadm striped parity RAID with Advanced Format drives
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• mdadm striped parity RAID with Advanced Format drives
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Raid5 boot failure after grow
  • From: Nikolay Kichukov <hijacker@xxxxxxxxx>
• upgrading the superblock version
  • From: Vasco Névoa <vasco.nevoa@xxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Erwan Leroux <erwan.lerou@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• [md PATCH 36/36] md/raid10: handle further errors during fix_read_error better.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 35/36] md/raid10: Handle read errors during recovery better.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 34/36] md/raid10: simplify read error handling during recovery.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 33/36] md/raid10: record bad blocks due to write errors during resync/recovery.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 32/36] md/raid10: attempt to fix read errors during resync/check
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 31/36] md/raid10: Handle write errors by updating badblock log.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 30/36] md/raid10: clear bad-block record when write succeeds.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 29/36] md/raid10: avoid writing to known bad blocks on known bad drives.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 28/36] md/raid10 record bad blocks as needed during recovery.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 27/36] md/raid10: avoid reading known bad blocks during resync/recovery.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 26/36] md/raid10 - avoid reading from known bad blocks - part 3
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 25/36] md/raid10: avoid reading from known bad blocks - part 2
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 24/36] md/raid10: avoid reading from known bad blocks - part 1
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 23/36] md/raid10: Split handle_read_error out from raid10d.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 22/36] md/raid10: simplify/reindent some loops.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 21/36] md/raid5: Clear bad blocks on successful write.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 20/36] md/raid5. Don't write to known bad block on doubtful devices.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 19/36] md/raid5: write errors should be recorded as bad blocks if possible.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 18/36] md/raid5: use bad-block log to improve handling of uncorrectable read errors.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 17/36] md/raid5: avoid reading from known bad blocks.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 16/36] md/raid1: factor several functions out or raid1d()
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 15/36] md/raid1: improve handling of read failure during recovery.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 14/36] md/raid1: record badblocks found during resync etc.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 13/36] md/raid1: Handle write errors by updating badblock log.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 12/36] md/raid1: store behind-write pages in bi_vecs.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 11/36] md/raid1: clear bad-block record when write succeeds.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 10/36] md/raid1: avoid writing to known-bad blocks on known-bad drives.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 09/36] md: make it easier to wait for bad blocks to be acknowledged.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 08/36] md: add 'write_error' flag to component devices.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 07/36] md/raid1: avoid reading known bad blocks during resync
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 06/36] md/raid1: avoid reading from known bad blocks.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 05/36] md: Disable bad blocks and v0.90 metadata.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 04/36] md: load/store badblock list from v1.x metadata
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 03/36] md: don't allow arrays to contain devices with bad blocks.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 02/36] md/bad-block-log: add sysfs interface for accessing bad-block-log.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 01/36] md: beginnings of bad block management.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 00/36] md patches for 3.1 - part 2: bad block logs
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 34/34] MD bitmap: Revert DM dirty log hooks
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 33/34] MD: raid1 s/sysfs_notify_dirent/sysfs_notify_dirent_safe
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 32/34] md/raid5: Avoid BUG caused by multiple failures.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 31/34] md/raid10: move rdev->corrected_errors counting
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 30/34] md/raid5: move rdev->corrected_errors counting
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 29/34] md/raid1: move rdev->corrected_errors counting
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 28/34] md: get rid of unnecessary casts on page_address()
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 27/34] md/raid10: Improve decision on whether to fail a device with a read error.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 26/34] md/raid10: Make use of new recovery_disabled handling
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 25/34] md: change managed of recovery_disabled.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 24/34] md: remove ro check in md_check_recovery()
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 23/34] md: introduce link/unlink_rdev() helpers
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 22/34] md/raid: use printk_ratelimited instead of printk_ratelimit
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 21/34] md: use proper little-endian bitops
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 20/34] md/raid5: finalise new merged handle_stripe.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 19/34] md/raid5: move some more common code into handle_stripe
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 18/34] md/raid5: move more common code into handle_stripe
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 16/34] md/raid5: unite fetch_block5 and fetch_block6
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 15/34] md/raid5: rearrange a test in fetch_block6.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 14/34] md/raid5: move more code into common handle_stripe
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 13/34] md/raid5: Move code for finishing a reconstruction into handle_stripe.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 12/34] md/raid5: move stripe_head_state and more code into handle_stripe.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 11/34] md/raid5: add some more fields to stripe_head_state
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 09/34] md/raid5: move common code into handle_stripe
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 07/34] md/raid5: Protect some more code with ->device_lock.
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 06/34] md/raid5: Remove use of sh->lock in sync_request
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 05/34] md/raid5: get rid of duplicated call to bio_data_dir()
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 04/34] md/raid5: use kmem_cache_zalloc()
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 03/34] md/raid10: share pages between read and write bio's during recovery
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 02/34] md/raid10: factor out common bio handling code
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 01/34] md/raid10: get rid of duplicated conditional expression
  • From: NeilBrown <neilb@xxxxxxx>
• [md PATCH 00/34] md patches for 3.1 - part 1
  • From: NeilBrown <neilb@xxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Problems with raid after reboot.
  • From: Matthew Tice <mjtice@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: "Pol Hallen" <raid1@xxxxxxxxxxxxxx>
• Re: [PATCH] MD: generate an event when array sync is complete
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [PATCH] RAID-6 check standalone suspend array V2.0
  • From: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
• Re: Raid5 boot failure after grow
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Raid5 boot failure after grow
  • From: Shaun Reich <predator106@xxxxxxxxx>
• RE: RAID 1 using SSD and 2 HDD
  • From: <brian.foster@xxxxxxx>
• RE: [PATCH] mdadm.8: Disk coercion with IMSM metadata.
  • From: "Naruszewicz, Maciej" <maciej.naruszewicz@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Werner Fischer <devlists@xxxxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: data corruption after rebuild
  • From: Pavel Herrmann <morpheus.ibis@xxxxxxxxx>
• Re: Software RAID and TRIM
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: data corruption after rebuild
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] MD bitmap: Revert DM dirty log hooks
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] MD: generate an event when array sync is complete
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] MD: raid1 s/sysfs_notify_dirent/sysfs_notify_dirent_safe
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Raid5 boot failure after grow
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Raid5 boot failure after grow
  • From: Shaun Reich <predator106@xxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Mike Power <mpower@xxxxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Roman Mamedov <rm@xxxxxxxxxx>
• Re: RAID 1 using SSD and 2 HDD
  • From: Roberto Spadim <roberto@xxxxxxxxxxxxx>
• RAID 1 using SSD and 2 HDD
  • From: Mike Power <mpower@xxxxxxxxxxxx>
• Re: data corruption after rebuild
  • From: Roman Mamedov <rm@xxxxxxxxxx>
• Re: data corruption after rebuild
  • From: Pavel Herrmann <morpheus.ibis@xxxxxxxxx>
• Re: data corruption after rebuild
  • From: Roman Mamedov <rm@xxxxxxxxxx>
• Re: data corruption after rebuild
  • From: Pavel Herrmann <morpheus.ibis@xxxxxxxxx>
• Re: data corruption after rebuild
  • From: Roman Mamedov <rm@xxxxxxxxxx>
• Re: data corruption after rebuild
  • From: Pavel Herrmann <morpheus.ibis@xxxxxxxxx>
• Re: data corruption after rebuild
  • From: Pavel Herrmann <morpheus.ibis@xxxxxxxxx>
• Re: data corruption after rebuild
  • From: Roman Mamedov <rm@xxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Tom De Mulder <tdm27@xxxxxxxxx>
• data corruption after rebuild
  • From: Pavel Herrmann <morpheus.ibis@xxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: "Tyler J. Wagner" <tyler@xxxxxxxxxxx>
• maybe a raid10 module issue?
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: Vasco Névoa <vasco.nevoa@xxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: "Tyler J. Wagner" <tyler@xxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: how to recover filesystem after clobbering array?
  • From: Vasco Névoa <vasco.nevoa@xxxxxxx>
• how to recover filesystem after clobbering array?
  • From: Vasco Névoa <vasco.nevoa@xxxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• [PATCH] Grow: fix version number in error message
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: Software RAID and TRIM
  • From: David Brown <david.brown@xxxxxxxxxxxx>
• SSDs vs. md/sync_speed_(min|max)
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• md stuck while rebuilding?
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Werner Fischer <devlists@xxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Tom De Mulder <tdm27@xxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Tom De Mulder <tdm27@xxxxxxxxx>
• Re: Software RAID and TRIM
  • From: David Brown <david@xxxxxxxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: Software RAID and TRIM
  • From: Lutz Vieweg <lvml@xxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Gordon Henderson <gordon@xxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Iustin Pop <iusty@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Iustin Pop <iusty@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: RAID5: failing an active component during spare rebuild - arrays hangs
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: "Pol Hallen" <raid1@xxxxxxxxxxxxxx>
• Re: standard performance (write speed 20Mb/s)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• standard performance (write speed 20Mb/s)
  • From: Pol Hallen <raid1@xxxxxxxxxxxxxx>
• Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH] MD bitmap: Revert DM dirty log hooks
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH] MD: generate an event when array sync is complete
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH] MD: raid1 s/sysfs_notify_dirent/sysfs_notify_dirent_safe
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: possible bug in md
  • From: Iordan Iordanov <iordan@xxxxxxxxxxxxxxx>
• sys/time.h missing from linux/raid/pq.h for userspace builds
  • From: Jaakko Kantojärvi <jaakko@xxxxxxxxx>
• Re: Reinstall OS Without Disturbing Software Raid Array
  • From: Simon Mcnair <simonmcnair@xxxxxxxxx>
• Re: [PATCH 3/3] md/raid10: move rdev->corrected_errors counting
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] md: get rid of unnecessary casts on page_address()
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] imsm: FIX: getinfo_super_imsm_volume() doesn't fill all disk information
  • From: NeilBrown <neilb@xxxxxxx>
• Re: possible bug in md
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] mdadm: fix build failures (ppc64)
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] md: remove ro check in md_check_recovery()
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH v2] md: introduce link/unlink_rdev() helpers
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.
  • From: NeilBrown <neilb@xxxxxxx>
• [PATCH] mdadm.8: Disk coercion with IMSM metadata.
  • From: "maciej.naruszewicz" <maciej.naruszewicz@xxxxxxxxx>
• RE: mdadm 3.1.4 - hanging on cat /proc/mdstat
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• mdadm 3.1.4 - hanging on cat /proc/mdstat
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• RE: Resolving mdadm built RAID issue
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• RE: Resolving mdadm built RAID issue
  • From: "Tyler J. Wagner" <tyler@xxxxxxxxxxx>
• RE: Resolving mdadm built RAID issue
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• Re: dm-crypt over raid6 unreadable after crash
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: dm-crypt over raid6 unreadable after crash
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: dm-crypt over raid6 unreadable after crash
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: dm-crypt over raid6 unreadable after crash
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>