Linux RAID Storage Date Index

• Thread Index

• Re: status of sas1068 ata-passthrough bug?
  • From: Cláudio Martins <ctpm@xxxxxxxxxx>
• Re: status of sas1068 ata-passthrough bug?
  • From: Michael Sallaway <michael@xxxxxxxxxxxx>
• Re: status of sas1068 ata-passthrough bug?
  • From: Cláudio Martins <ctpm@xxxxxxxxxx>
• Re: reshape success story
  • From: Neil Brown <neilb@xxxxxxx>
• Re: status of sas1068 ata-passthrough bug?
  • From: Matt Garman <matthew.garman@xxxxxxxxx>
• Re: status of sas1068 ata-passthrough bug?
  • From: Cláudio Martins <ctpm@xxxxxxxxxx>
• Re: Upgraded grub, now confused about mirrored /boot
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• RE: Upgraded grub, now confused about mirrored /boot
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Upgraded grub, now confused about mirrored /boot
  • From: "Guy Watkins" <linux-raid@xxxxxxxxxxxxxxxx>
• Re: reshape success story
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• status of sas1068 ata-passthrough bug?
  • From: Matt Garman <matthew.garman@xxxxxxxxx>
• RE: Samsung F1 RAID Class SATA/300 1TB drives
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• RE: argh!
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: David Rees <drees76@xxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: argh!
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: argh!
  • From: Neil Brown <neilb@xxxxxxx>
• Re: argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: argh!
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3T drives and RAID
  • From: Bernd Schubert <bernd.schubert@xxxxxxxxxxx>
• Re: argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: reshape success story
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3T drives and RAID
  • From: Neil Brown <neilb@xxxxxxx>
• Re: reshape success story
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• reshape success story
  • From: Florian Dazinger <flockmock@xxxxxxxxx>
• RE: argh!
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• RE: argh!
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• RE: argh!
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• RE: argh!
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: argh!
  • From: Phil Turmel <philip@xxxxxxxxxx>
• argh!
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• RE: 3T drives and RAID
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: 3T drives and RAID
  • From: Johannes Truschnigg <johannes@xxxxxxxxxxxxxxx>
• 3T drives and RAID
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• When does the raid bitmap actually work.
  • From: Daniel Reurich <daniel@xxxxxxxxxxxxxxxx>
• Re: mdadm / RAID, a few questions
  • From: Neil Brown <neilb@xxxxxxx>
• Re: mdadm / RAID, a few questions
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: mdadm / RAID, a few questions
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• [PATCH] IMSM: update to function generating unique volume id.
  • From: Artur Wojcik <artur.wojcik@xxxxxxxxx>
• [PATCH 17/17] Policy is aware of metadata disk's controller domains.
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 16/17] IMSM: Fix problem in mdmon monitor of using removed disk from in imsm container.
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 15/17] Monitor: more accurate size check when looking for spares
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 14/17] Monitor: Respect policy in auto-rebuild in mdadm monitoring.
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 13/17] Monitor: autorebuild functionality added
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 12/17] imsm: create mdinfo list of disks in a container from supertype
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 11/17] Monitor: link containers with subarrays in statelist
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 10/17] Monitor: include containers in scan mode
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 09/17] Monitor: avoid skipping checks on external arays
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 08/17] mdadm: added --no-sharing option for Monitor mode
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 07/17] Monitor: spare-group based spare sharing moved to separate function
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 06/17] Monitor: set err on arrays not in mdstat
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 05/17] Util: get device size from id
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 04/17] Incremental for bare disks, implementation of spare-same port policy action
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• mdadm / RAID, a few questions
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• [PATCH 03/17] extension of IncrementalRemove to store location (path-id) of removed device
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 02/17] Update of udev rules to support IMSM devices
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [Patch 00/17] Autorebuild
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 01/17] added --path <path_id> to give the information on the 'path-id' of removed device
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PULL REQUEST] md update for current merge window
  • From: Neil Brown <neilb@xxxxxxx>
• RE: Autorebuild - many instances of Monitor?
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: Mark Knecht <markknecht@xxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Samsung F1 RAID Class SATA/300 1TB drives
  • From: Mark Knecht <markknecht@xxxxxxxxx>
• Re: Autorebuild - many instances of Monitor?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: sw raid5 hungs on resync and high IO load, 2.6.32.23
  • From: Martin Hamrle <martin.hamrle@xxxxxxxx>
• Re: sw raid5 hungs on resync and high IO load, 2.6.32.23
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: sw raid5 hungs on resync and high IO load, 2.6.32.23
  • From: Neil Brown <neilb@xxxxxxx>
• Autorebuild - many instances of Monitor?
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• sw raid5 hungs on resync and high IO load, 2.6.32.23
  • From: Martin Hamrle <martin.hamrle@xxxxxxxx>
• Re: MD RAID1 deadlock on failed disk
  • From: Neil Brown <neilb@xxxxxxx>
• Re: MD RAID1 deadlock on failed disk
  • From: Hubert Tonneau <hubert.tonneau@xxxxxxxxxxxxxx>
• MD RAID1 deadlock on failed disk
  • From: Hubert Tonneau <hubert.tonneau@xxxxxxxxxxxxxx>
• Re: Help!
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: [PATCH 2/2] md/raid5: initialize ->recovery_offset when growing raid_disks
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 2/2] md/raid5: initialize ->recovery_offset when growing raid_disks
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 2/2] md/raid5: initialize ->recovery_offset when growing raid_disks
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 1/2] md/raid5: skip wait for MD_CHANGE_DEVS acknowledgement in the external case
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 2/2] md/raid5: initialize ->recovery_offset when growing raid_disks
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 1/2] md/raid5: skip wait for MD_CHANGE_DEVS acknowledgement in the external case
  • From: Neil Brown <neilb@xxxxxxx>
• [PATCH 1/2] md/raid5: skip wait for MD_CHANGE_DEVS acknowledgement in the external case
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 2/2] md/raid5: initialize ->recovery_offset when growing raid_disks
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 0/2] reshape fixlets for 2.6.37
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Help!
  • From: Jesús Bermúdez <jbermudez@xxxxxxx>
• Re: problems with "LSISAS2008 6Gb/s SAS" kernel mpt2sas driver
  • From: Stefan /*St0fF*/ Hübner <stefan.huebner@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 18/22] md: use little-endian bit operations
  • From: Akinobu Mita <akinobu.mita@xxxxxxxxx>
• Re: problems with "LSISAS2008 6Gb/s SAS" kernel mpt2sas driver
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: problems with "LSISAS2008 6Gb/s SAS" kernel mpt2sas driver
  • From: Tim Small <tim@xxxxxxxxxxx>
• problems with "LSISAS2008 6Gb/s SAS" kernel mpt2sas driver
  • From: Louis-David Mitterrand <vindex+lists-linux-raid@xxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• RE: [AUTOREBUILD 0/8] Autorebuild monitor patches based on user defined policy
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Linux raid resyncing for unknown reasons
  • From: Nagilum <nagilum@xxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: [AUTOREBUILD 0/8] Autorebuild monitor patches based on user defined policy
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: booting into /dev/md0 after an upgrade to squeeze - SOLVED
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [AUTOREBUILD 0/8] Autorebuild monitor patches based on user defined policy
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Problem regarding RAID10 on kernel 2.6.31
  • From: Neil Brown <neilb@xxxxxxx>
• RE: Problem regarding RAID10 on kernel 2.6.31
  • From: Hari Subramanian <hari@xxxxxxxxxx>
• Re: booting into /dev/md0 after an upgrade to squeeze
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: booting into /dev/md0 after an upgrade to squeeze
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• booting into /dev/md0 after an upgrade to squeeze
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: Preventing a RAID device from starting until all disks are ready
  • From: Iordan Iordanov <iordan@xxxxxxxxxxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH 18/22] md: use little endian bit operations
  • From: Neil Brown <neilb@xxxxxxx>
• [PATCH 18/22] md: use little endian bit operations
  • From: Akinobu Mita <akinobu.mita@xxxxxxxxx>
• Re: Preventing a RAID device from starting until all disks are ready
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: Preventing a RAID device from starting until all disks are ready
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Preventing a RAID device from starting until all disks are ready
  • From: Andrew Klaassen <clawsoon@xxxxxxxxx>
• Re: Preventing a RAID device from starting until all disks are ready
  • From: Andrew Klaassen <clawsoon@xxxxxxxxx>
• Re: Preventing a RAID device from starting until all disks are ready
  • From: Iordan Iordanov <iordan@xxxxxxxxxxxxxxx>
• Preventing a RAID device from starting until all disks are ready
  • From: Andrew Klaassen <clawsoon@xxxxxxxxx>
• Re: bitmap questions
  • From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxx>
• Re: bitmap questions
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• [resolved] Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Simon SÉHIER <simon@xxxxxxxxx>
• Re: bitmap questions
  • From: Arkadiusz Miskiewicz <a.miskiewicz@xxxxxxxxx>
• Re: bitmap questions
  • From: Paul Clements <paul.clements@xxxxxxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Complexity of toggling write-behind.
  • From: Neil Brown <neilb@xxxxxxx>
• Complexity of toggling write-behind.
  • From: greg@xxxxxxxxxxxx
• Swap over RAID1 hangs kernel
  • From: Torsten Kaiser <just.for.lkml@xxxxxxxxxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Simon SÉHIER <simon@xxxxxxxxx>
• bitmap questions
  • From: Arkadiusz Miskiewicz <a.miskiewicz@xxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Simon SÉHIER <simon@xxxxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Simon SEHIER <simon@xxxxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Simon SÉHIER <simon@xxxxxxxxx>
• Re: reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: raid0 and discard/trim - current state?
  • From: Mike Snitzer <snitzer@xxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: can mdadm use /dev/sgX as devices?
  • From: Harry Mangalam <harry.mangalam@xxxxxxx>
• reboot before reshape from raid 5 to raid 6 (was in state resync=DELAYED). Doesn't assemble anymore.
  • From: Simon S <simon@xxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: can mdadm use /dev/sgX as devices?
  • From: Tim Small <tim@xxxxxxxxxxx>
• Linux raid resyncing for unknown reasons
  • From: Job Honig <joho@xxxxxxxxx>
• Re: can mdadm use /dev/sgX as devices?
  • From: "Majed B." <majedb@xxxxxxxxx>
• can mdadm use /dev/sgX as devices?
  • From: Harry Mangalam <harry.mangalam@xxxxxxx>
• Re: RAID0 size bug (?)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: RAID0 size bug (?)
  • From: "Janos Haar" <janos.haar@xxxxxxxxxxxx>
• Re: raid0 and discard/trim - current state?
  • From: DagB <dag@xxxxxxxxx>
• raid0 and discard/trim - current state?
  • From: DagB <dag@xxxxxxxxx>
• Re: RAID0 size bug (?)
  • From: Neil Brown <neilb@xxxxxxx>
• RAID0 size bug (?)
  • From: "Janos Haar" <janos.haar@xxxxxxxxxxxx>
• Re: Ok, dumb question time ...
  • From: Joe Landman <landman@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: Ok, dumb question time ...
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Stefan /*St0fF*/ Hübner <stefan.huebner@xxxxxxxxxxxxxxxxxx>
• Re: Ok, dumb question time ...
  • From: Joe Landman <joe.landman@xxxxxxxxx>
• Re: Ok, dumb question time ...
  • From: Neil Brown <neilb@xxxxxxx>
• Ok, dumb question time ...
  • From: Joe Landman <landman@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PULL request] md fixes for 2.6.36
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: Debian kernel stanza after aptitude kernel upgrade
  • From: Neil Brown <neilb@xxxxxxx>
• [PULL request] md fixes for 2.6.36
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Michael Sallaway <michael@xxxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Lemur Kryptering <gottail@xxxxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Lemur Kryptering <gottail@xxxxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Stefan /*St0fF*/ Hübner <stefan.huebner@xxxxxxxxxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Richard Scobie <richard@xxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Lemur Kryptering <gottail@xxxxxxxxxxxxx>
• Re: Raid 6 - TLER/CCTL/ERC
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Raid 6 - TLER/CCTL/ERC
  • From: Peter Zieba <pzieba@xxxxxxxxxxxxxxxxx>
• Re: RAID5 hangs on startup when 1 of 5 drives is disconnected.
  • From: Hank Barta <hbarta@xxxxxxxxx>
• Re: Restoring data from linear raid
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Restoring data from linear raid
  • From: Pavel Shevaev <pacha.shevaev@xxxxxxxxx>
• Re: Accidental grow before add
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Accidental grow before add
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Why does MD overwrite the superblock upon temporary disconnect?
  • From: Neil Brown <neilb@xxxxxxx>
• RAID1 hangs on startup when 1 of 5 drives is disconnected.
  • From: Hank Barta <hbarta@xxxxxxxxx>
• RE: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Tirumala Marri <tmarri@xxxxxxx>
• Re: [Bug 19642] New: 2.6.36-rc6 BUG at drivers/scsi/scsi_lib.c:1113
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Q: how to move "spare" back into raid?
  • From: Henrik Holst <holst@xxxxxxxxxxx>
• Re: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Greg KH <greg@xxxxxxxxx>
• RE: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Tirumala Marri <tmarri@xxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• [AUTOREBUILD 8/8] Monitor: Helper functions added for spare_sharing in monitor
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• RE: [AUTOREBUILD 7/8] Monitor: Respect policy in auto-rebuild in mdadm monitoring.
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• RE: [AUTOREBUILD 5/8] imsm: create mdinfo list of disks in a container from supertype
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [AUTOREBUILD 6/8] Monitor: autorebuild functionality added
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [AUTOREBUILD 3/8] mdadm: added --no-sharing parameter for Monitor mode
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [AUTOREBUILD 4/8] Monitor: link container-volumes in statelist
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [AUTOREBUILD 2/8] Monitor: removed spare-group based spare sharing code
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [AUTOREBUILD 1/8] Monitor: set err on arrays not in mdstat
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• [AUTOREBUILD 0/8] Autorebuild monitor patches based on user defined policy
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: 2.6.36-rc6 BUG at drivers/scsi/scsi_lib.c:1113
  • From: "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>
• Re: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• RE: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Tirumala Marri <tmarri@xxxxxxx>
• RE: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Tirumala Marri <tmarri@xxxxxxx>
• Re: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• 2.6.36-rc6 BUG at drivers/scsi/scsi_lib.c:1113
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH] PPC4xx: ADMA separating SoC specific functions
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: raid5+hotspare: request for recommended procedure
  • From: Tim Small <tim@xxxxxxxxxxx>
• raid5+hotspare: request for recommended procedure
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: 3-way mirrors
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Nagilum <nagilum@xxxxxxxxxxx>
• Re: Debian kernel stanza after aptitude kernel upgrade
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: RAID 5 with bad blocks
  • From: Daniel Reurich <daniel@xxxxxxxxxxxxxxxx>
• Re: RAID 5 with bad blocks
  • From: "Carl-Johan Wägner" <carl-johan.wagner@xxxxxxxxx>
• Q: how to move "spare" back into raid?
  • From: Henrik Holst <holst@xxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: Accidental grow before add
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Accidental grow before add
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: RAID 5 with bad blocks
  • From: "Carl-Johan Wägner" <carl-johan.wagner@xxxxxxxxx>
• Re: How do I repair a checksum error in the superblock?
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: How do I repair a checksum error in the superblock?
  • From: Neil Brown <neilb@xxxxxxx>
• RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Tirumala Marri <tmarri@xxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.4 - A tool for managing Soft RAID under Linux
  • From: Jools Wills <jools@xxxxxxxxxxxxxxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.4 - A tool for managing Soft RAID under Linux
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Stefan Roese <sr@xxxxxxx>
• Re: How to remove non-existant device
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• How do I repair a checksum error in the superblock?
  • From: Adam Newham <adam@xxxxxxxxxxxxxx>
• Re: [PATCH v1 1/4] PPC4xx: Generalizing ADMA driver modifications
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH v1 3/4] PPC4xx: New file with SoC specific functions
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Tirumala Marri <tmarri@xxxxxxx>
• RE: [PATCH v1 1/4] PPC4xx: Generalizing ADMA driver modifications
  • From: Tirumala Marri <tmarri@xxxxxxx>
• Re: [PATCH v1 1/4] PPC4xx: Generalizing ADMA driver modifications
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH v1 2/4] PPC4xx: New header with SoC specific dfinitions
  • From: tmarri@xxxxxxx
• [PATCH v1 4/4] PPC4xx: Merge files to create single 440spe header
  • From: tmarri@xxxxxxx
• [PATCH v1 3/4] PPC4xx: New file with SoC specific functions
  • From: tmarri@xxxxxxx
• Re: How to remove non-existant device
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 2/2] PPC4xx: Merge xor.h and dma.h into onefile ppc440spe-dma.h
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: mdadm raid5 array - 0 space available but usage is less than capacity
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: mdadm raid5 array - 0 space available but usage is less than capacity
  • From: Kaizaad Bilimorya <kaizaad@xxxxxxxxxxx>
• Re: mdadm raid5 array - 0 space available but usage is less than capacity
  • From: Marcus Kool <marcus@xxxxxxxxxxxxxxx>
• Re: mdadm raid5 array - 0 space available but usage is less than capacity
  • From: Robin Doherty <rdoherty@xxxxxxxxx>
• Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: mdadm raid5 array - 0 space available but usage is less than capacity
  • From: Robin Doherty <rdoherty@xxxxxxxxx>
• mdadm raid5 array - 0 space available but usage is less than capacity
  • From: Robin Doherty <rdoherty@xxxxxxxxx>
• Re: How to remove non-existant device
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: How to remove non-existant device
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Is this likely to cause me problems?
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: idr_get_new_exact ?
  • From: Tejun Heo <htejun@xxxxxxxxx>
• Re: idr_get_new_exact ?
  • From: Paul Mundt <lethal@xxxxxxxxxxxx>
• How to remove non-existant device
  • From: Benjamin Schieder <blindcoder@xxxxxxxxxxxxxxxxxxxx>
• Re: How to prevent auto assembly?
  • From: Neil Brown <neilb@xxxxxxx>
• How to prevent auto assembly?
  • From: Jim Schatzman <james.schatzman@xxxxxxxxxxxxxxxx>
• Re: Is this likely to cause me problems?
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: Is this likely to cause me problems?
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Is this likely to cause me problems?
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Is this likely to cause me problems?
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.4 - A tool for managing Soft RAID under Linux
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Is this likely to cause me problems?
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Is this likely to cause me problems?
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: Is this likely to cause me problems?
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Is this likely to cause me problems?
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: Debian kernel stanza after aptitude kernel upgrade
  • From: Neil Brown <neilb@xxxxxxx>
• Re: a general question re. linux-raid stability
  • From: Andre Tomt <andre@xxxxxxxx>
• Re: Debian kernel stanza after aptitude kernel upgrade
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Debian kernel stanza after aptitude kernel upgrade
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Debian kernel stanza after aptitude kernel upgrade
  • From: "A. Krijgsman" <a.krijgsman@xxxxxxxxxxxx>
• Re: a general question re. linux-raid stability
  • From: Miles Fidelman <mfidelman@xxxxxxxxxxxxxxxx>
• Re: Why does MD overwrite the superblock upon temporary disconnect?
  • From: Jim Schatzman <james.schatzman@xxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Debian kernel stanza after aptitude kernel upgrade
  • From: "A. Krijgsman" <a.krijgsman@xxxxxxxxxxxx>
• Re: a general question re. linux-raid stability
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Why does MD overwrite the superblock upon temporary disconnect?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Why does MD overwrite the superblock upon temporary disconnect?
  • From: Richard Scobie <richard@xxxxxxxxxxx>
• Why does MD overwrite the superblock upon temporary disconnect?
  • From: Jim Schatzman <james.schatzman@xxxxxxxxxxxxxxxx>
• Re: a general question re. linux-raid stability
  • From: Daniel Reurich <daniel@xxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Neil Brown <neilb@xxxxxxx>
• a general question re. linux-raid stability
  • From: Miles Fidelman <mfidelman@xxxxxxxxxxxxxxxx>
• Re: [dm-devel] idr_get_new_exact ?
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: idr_get_new_exact ?
  • From: Tejun Heo <htejun@xxxxxxxxx>
• Re: idr_get_new_exact ?
  • From: Roland Dreier <rdreier@xxxxxxxxx>
• Re: idr_get_new_exact ?
  • From: Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx>
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: idr_get_new_exact ?
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Tirumala Marri <tmarri@xxxxxxx>
• idr_get_new_exact ?
  • From: Ohad Ben-Cohen <ohad@xxxxxxxxxx>
• Re: some non critical problems... (1. mdadm segfault -> write-mostly, 2. smart?)
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: [PATCH 2/2] PPC4xx: Merge xor.h and dma.h into onefile ppc440spe-dma.h
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: [dm-devel] [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxx>
• Re: some non critical problems... (1. mdadm segfault -> write-mostly, 2. smart?)
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: raid10f2. mismatch_cnt=128. 'repair' does nothing.
  • From: Neil Brown <neilb@xxxxxxx>
• raid10f2. mismatch_cnt=128. 'repair' does nothing.
  • From: Jon Nelson <jnelson-linux-raid@xxxxxxxxxxx>
• [PATCH 2/2] PPC4xx: Merge xor.h and dma.h into onefile ppc440spe-dma.h
  • From: tmarri@xxxxxxx
• Re: Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Neil Brown <neilb@xxxxxxx>
• mdadm RAID safety checks?
  • From: Nagilum <nagilum@xxxxxxxxxxx>
• Deadlock in md barrier code? / RAID1 / LVM CoW snapshot + ext3 / Debian 5.0 - lenny 2.6.26 kernel
  • From: Tim Small <tim@xxxxxxxxxxx>
• RAID 5 with bad blocks
  • From: Lasse Jensen <fafler@xxxxxxxxx>
• [PULL REQUEST] 2 minor md patches for 2.6.36
  • From: Neil Brown <neilb@xxxxxxx>
• Raid MBR
  • From: Pascal Nobus <pascal@xxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.4 - A tool for managing Soft RAID under Linux
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Neil Brown <neilb@xxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Avi Kivity <avi@xxxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Keld Jørn Simonsen <keld@xxxxxxxxxx>
• Re: Endian issue assembling arrays
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: RAID 5+1 with mdadm
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• Fwd: Endian issue assembling arrays
  • From: Doug Nazar <nazard.michi@xxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: "Pol Hallen" <polhallen@xxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• RAID 5+1 with mdadm
  • From: Peter Krauss <peter.krauss@xxxxxxxxxxxxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Keld Jørn Simonsen <keld@xxxxxxxxxx>
• Re: advice to low cost hardware raid (with mdadm)
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• advice to low cost hardware raid (with mdadm)
  • From: "Pol Hallen" <polhallen@xxxxxxxxxxxxxx>
• Re: [raid5] 3 disks, after tests 2 spares disks
  • From: "Pol Hallen" <polhallen@xxxxxxxxxxxxxx>
• Re: [raid5] 3 disks, after tests 2 spares disks
  • From: "Pol Hallen" <polhallen@xxxxxxxxxxxxxx>
• Re: raid6 and parity calculations
  • From: Andre Noll <maan@xxxxxxxxxxxxxxx>
• Re: raid6 and parity calculations
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: raid6 and parity calculations
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [raid5] 3 disks, after tests 2 spares disks
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [raid5] 3 disks, after tests 2 spares disks
  • From: "Pol Hallen" <raid1@xxxxxxxxxxxxxx>
• raid6 and parity calculations
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• Re: some non critical problems... (1. mdadm segfault -> write-mostly, 2. smart?)
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: New RAID causing system lockups
  • From: Neil Brown <neilb@xxxxxxx>
• mdadm 3.1.3 call trace crash on Ubuntu 10.04 64-bit
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Neil Brown <neilb@xxxxxxx>
• RE: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Q: mdadm as implemented in Openfiler
  • From: maurice <mhilarius@xxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: New RAID causing system lockups
  • From: Neil Brown <neilb@xxxxxxx>
• Re: New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• New RAID causing system lockups
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: How to initialize "composite" RAID
  • From: Wolfgang Denk <wd@xxxxxxx>
• How to initialize "composite" RAID
  • From: Mike Hartman <mike@xxxxxxxxxxxxxxxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: CoolCold <coolthecold@xxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Norman White <nwhite@xxxxxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: "Mr. James W. Laferriere" <babydr@xxxxxxxxxxxxxxxx>
• Virtual unplug (was Re: [PATCH 26/30] ext4: do not send discards as barriers)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Norman White <nwhite@xxxxxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: cpu_relax() usage in raid6algos.c
  • From: Neil Brown <neilb@xxxxxxx>
• cpu_relax() usage in raid6algos.c
  • From: Drew <drew.kay@xxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: 3-way mirrors
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3-way mirrors
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
• 5 drives lost in an inactive 15 drive raid 6 system due to cable problem - how to recover?
  • From: Norman White <nwhite@xxxxxxxxxxxxx>
• Re: [PATCHSET #upstream] block, fs: replace HARDBARRIER with FLUSH/FUA, take#2
  • From: Tejun Heo <teheo@xxxxxxx>
• Re: [PATCH 42/41 v2] dm: convey that all flushes are processed as empty
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 42/41 v2] dm: convey that all flushes are processed as empty
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: 3-way mirrors
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: RAID mismatches (and reporting thereof)
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: some non critical problems... (1. mdadm segfault -> write-mostly, 2. smart?)
  • From: Janek Kozicki <janek_listy@xxxxx>
• RAID mismatches (and reporting thereof)
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3-way mirrors
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3-way mirrors
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3-way mirrors
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Neil Brown <neilb@xxxxxxx>
• Re: 3-way mirrors
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• [PATCH 42/41 v2] dm: convey that all flushes are processed as empty
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 24/41] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 42/41] dm: convey that all flushes are processed as empty
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 42/41] dm: convey that all flushes are processed as empty
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: 3-way mirrors
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Keld Jørn Simonsen <keld@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Kulikov Vasiliy <segooon@xxxxxxxxx>
• Re: 3-way mirrors
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: 3-way mirrors
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: 3-way mirrors
  • From: Aryeh Gregor <Simetrical+list@xxxxxxxxx>
• Re: 3-way mirrors
  • From: Iordan Iordanov <iordan@xxxxxxxxxxxxxxx>
• 3-way mirrors
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH] Add optional round-robbin read balancing to RAID1
  • From: Jan Ceuleers <jan.ceuleers@xxxxxxxxxxxx>
• rebuilding a RAID6 array, and ignoring bad sectors?
  • From: "Michael Sallaway" <michael@xxxxxxxxxxxx>
• Re: [PATCH] Add optional round-robbin read balancing to RAID1
  • From: Roy Keene <linux-raid@xxxxxxxxxx>
• Re: [PATCH] Add optional round-robbin read balancing to RAID1
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: [PATCH] Add optional round-robbin read balancing to RAID1
  • From: Neil Brown <neilb@xxxxxxx>
• [PATCH] Add optional round-robbin read balancing to RAID1
  • From: Roy Keene <rkeene@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• some non critical problems... (1. mdadm segfault -> write-mostly, 2. smart?)
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: some non critical problems... (1. mdadm segfault -> write-mostly, 2. smart?)
  • From: Janek Kozicki <janek_listy@xxxxx>
• Re: [PATCH 24.5/30] jbd2: Modify ASYNC_COMMIT code to not rely on queue draining on barrier
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH 24.5/30] jbd2: Modify ASYNC_COMMIT code to not rely on queue draining on barrier
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [dm-devel] [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: walter harms <wharms@xxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• RAID-10: changing one (non-failed) drive for another
  • From: Ondrej Jombik <jombik@xxxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Kulikov Vasiliy <segooon@xxxxxxxxx>
• Re: [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH] md: do not use ++ in rcu_dereference() argument
  • From: Kulikov Vasiliy <segooon@xxxxxxxxx>
• [PATCH 03/14] md: check return code of read_sb_page
  • From: Kulikov Vasiliy <segooon@xxxxxxxxx>
• Re: the true behavior of mdadm's raid-1 with regard to vertical parity and silent error detection/scrubbing- confirmation or feature request
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: the true behavior of mdadm's raid-1 with regard to vertical parity and silent error detection/scrubbing- confirmation or feature request
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [PATCH] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 12/41] block: simplify queue_next_fseq
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCHSET #upstream] block, fs: replace HARDBARRIER with FLUSH/FUA, take#2
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 01/41] ide: remove unnecessary blk_queue_flushing() test in do_ide_request()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 13/41] block: initialize flush request with WRITE_FLUSH instead of REQ_FLUSH
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 19/41] virtio_blk: drop REQ_HARDBARRIER support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 06/41] block: misc cleanups in barrier code
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 22/41] block: make __blk_rq_prep_clone() copy most command flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 16/41] block: update documentation for REQ_FLUSH / REQ_FUA
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 11/41] block: filter flush bio's in __generic_make_request()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 14/41] block: kick queue after sequencing REQ_FLUSH/FUA
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 18/41] block/loop: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 05/41] block: remove spurious uses of REQ_HARDBARRIER
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 15/41] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 17/41] block: use REQ_FLUSH in blkdev_issue_flush()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 07/41] block: drop barrier ordering by queue draining
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 03/41] block: kill QUEUE_ORDERED_BY_TAG
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 27/41] block: pass gfp_mask and flags to sb_issue_discard
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 09/41] block: rename barrier/ordered to flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 31/41] reiserfs: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 26/41] dm: fix locking context in queue_io()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 30/41] gfs2: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 37/41] fat: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 36/41] ext4: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 20/41] lguest: replace VIRTIO_F_BARRIER support with VIRTIO_F_FLUSH support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 39/41] block: remove the WRITE_BARRIER flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 08/41] block: rename blk-barrier.c to blk-flush.c
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 24/41] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 40/41] block: remove the BLKDEV_IFL_BARRIER flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 32/41] nilfs2: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 25/41] dm: relax ordering of bio-based flush implementation
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 34/41] jbd2: Modify ASYNC_COMMIT code to not rely on queue draining on barrier
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 35/41] jbd2: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 28/41] xfs: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 41/41] block: remove the BH_Eopnotsupp flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 21/41] md: implment REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 33/41] jbd: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 29/41] btrfs: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 10/41] block: implement REQ_FLUSH/FUA based interface for FLUSH/FUA requests
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 23/41] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 04/41] block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• [PATCH 38/41] swap: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 02/41] block/loop: queue ordered mode should be DRAIN_FLUSH
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 3/5] dm: relax ordering of bio-based flush implementation
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: Setting /sys/block/mdX/md/rdY/size caps to half the true value of the component device size
  • From: Chris Webb <chris@xxxxxxxxxxxx>
• Re: [PATCH 3/5] dm: relax ordering of bio-based flush implementation
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [PATCH] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Vladislav Bolkhovitin <vst@xxxxxxxx>
• [PATCH] block: make sure FSEQ_DATA request has the same rq_disk as the original
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Setting /sys/block/mdX/md/rdY/size caps to half the true value of the component device size
  • From: "Martin Lui" <linuxdevel@xxxxxxxxxxxxxx>
• [patch v2 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH 1/5] block: make __blk_rq_prep_clone() copy most command flags
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 3/5] dm: relax ordering of bio-based flush implementation
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/5] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/5] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 3/5] dm: relax ordering of bio-based flush implementation
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/5] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/5] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: safety of retrying SYNCHRONIZE CACHE [was: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush]
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: safety of retrying SYNCHRONIZE CACHE [was: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush]
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• safety of retrying SYNCHRONIZE CACHE [was: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• ANNOUNCE: mdadm 3.1.4 - A tool for managing Soft RAID under Linux
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Vladislav Bolkhovitin <vst@xxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Vladislav Bolkhovitin <vst@xxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH UPDATED 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH] block: initialize flush request with WRITE_FLUSH instead of REQ_FLUSH
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 04/30] block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush()
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [dm-devel] [RFC] training mpath to discern between SCSI errors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: Sergei Shtylyov <sshtylyov@xxxxxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH 2/5] dm: implement REQ_FLUSH/FUA support for bio-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 3/5] dm: relax ordering of bio-based flush implementation
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 5/5] block: remove the WRITE_BARRIER flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 1/5] block: make __blk_rq_prep_clone() copy most command flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCHSET 2.6.36-rc2] block, dm: finish REQ_FLUSH/FUA conversion, take#2
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 4/5] dm: implement REQ_FLUSH/FUA support for request-based dm
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PULL REQUEST] minor md updates.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH] lib/raid6: ignore generated files
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH 2/4] dm: implement REQ_FLUSH/FUA support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/4] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/4] dm: implement REQ_FLUSH/FUA support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 1/4] block: make __blk_rq_prep_clone() copy most command flags
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCHSET 2.6.36-rc2] block, dm: finish REQ_FLUSH/FUA conversion
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 1/4] block: make __blk_rq_prep_clone() copy most command flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 2/4] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 3/4] dm: relax ordering of bio-based flush implementation
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCHSET 2.6.36-rc2] block, dm: finish REQ_FLUSH/FUA conversion
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 4/4] block: remove the WRITE_BARRIER flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [PATCH] block: update documentation for REQ_FLUSH / REQ_FUA
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Christoph Lameter <cl@xxxxxxxxx>
• [PATCH] block: update documentation for REQ_FLUSH / REQ_FUA
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH UPDATED 24.5/30] jbd2: Modify ASYNC_COMMIT code to not rely on queue draining on barrier
  • From: Tejun Heo <teheo@xxxxxxx>
• Re: [PATCH 24.5/30] jbd2: Modify ASYNC_COMMIT code to not rely on queue draining on barrier
  • From: Sergei Shtylyov <sshtylyov@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH 24.5/30] jbd2: Modify ASYNC_COMMIT code to not rely on queue draining on barrier
  • From: Tejun Heo <teheo@xxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Jan Kara <jack@xxxxxxx>
• Re: [RFC] training mpath to discern between SCSI errors
  • From: Mike Christie <michaelc@xxxxxxxxxxx>
• [PATCH 21/30] gfs2: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 20/30] btrfs: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 02/30] block/loop: queue ordered mode should be DRAIN_FLUSH
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 12/30] block: use REQ_FLUSH in blkdev_issue_flush()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 15/30] virtio_blk: drop REQ_HARDBARRIER support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCHSET 2.6.36-rc2] block, fs: replace HARDBARRIER with FLUSH/FUA
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 07/30] block: drop barrier ordering by queue draining
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 01/30] ide: remove unnecessary blk_queue_flushing() test in do_ide_request()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 13/30] block: simplify queue_next_fseq
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 08/30] block: rename blk-barrier.c to blk-flush.c
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 27/30] fat: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 30/30] block: remove the BH_Eopnotsupp flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 26/30] ext4: do not send discards as barriers
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 29/30] block: remove the BLKDEV_IFL_BARRIER flag
  • From: Christoph Hellwig <hch@xxxxxx>
• [RFC] training mpath to discern between SCSI errors (was: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 09/30] block: rename barrier/ordered to flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 29/30] block: remove the BLKDEV_IFL_BARRIER flag
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCHSET 2.6.36-rc2] block, fs: replace HARDBARRIER with FLUSH/FUA
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 11/30] block: filter flush bio's in __generic_make_request()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 06/30] block: misc cleanups in barrier code
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 10/30] block: implement REQ_FLUSH/FUA based interface for FLUSH/FUA requests
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 17/30] md: implment REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 28/30] swap: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 14/30] block/loop: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 03/30] block: kill QUEUE_ORDERED_BY_TAG
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 16/30] lguest: replace VIRTIO_F_BARRIER support with VIRTIO_F_FLUSH support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 26/30] ext4: do not send discards as barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 22/30] reiserfs: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 18/30] block: pass gfp_mask and flags to sb_issue_discard
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 05/30] block: remove spurious uses of REQ_HARDBARRIER
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 04/30] block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 19/30] xfs: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 23/30] nilfs2: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 25/30] jbd2: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 24/30] jbd: replace barriers with explicit flush / FUA usage
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Theodore Tso <tytso@xxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: [PATCH UPDATED 4/5] md: implment REQ_FLUSH/FUA support
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• [PATCH UPDATED 4/5] md: implment REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Vladislav Bolkhovitin <vst@xxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [RFC PATCHSET block#for-2.6.36-post] block: convert to REQ_FLUSH/FUA
  • From: Philipp Reisner <philipp.reisner@xxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: Jan Kara <jack@xxxxxxx>
• [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: [RFC PATCHSET block#for-2.6.36-post] block: convert to REQ_FLUSH/FUA
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [PATCH 4/5] md: implment REQ_FLUSH/FUA support
  • From: Neil Brown <neilb@xxxxxxx>
• Re: A policy frame work for mdadm (incorporating domains and hotplug and such)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: Pekka Enberg <penberg@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: Pekka Enberg <penberg@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH] lib/raid6: ignore generated files
  • From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>