Linux RAID Storage Date Index

• Thread Index

• Re: Autorebuild, new dynamic udev rules for hot-plugs
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 13/13] External reshape (step 2): Freeze container
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Autorebuild, new dynamic udev rules for hot-plugs
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 12/13] External reshape (step 1): container reshape and ->reshape_super()
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Autorebuild, new dynamic udev rules for hot-plugs
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 11/13] Document the external reshape implementation
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 07/13] Grow: add missing raid4 geometries to geo_map()
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 03/13] Manage: allow manual control of external raid0 readonly flag
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 02/13] block monitor: freeze spare assignment for external arrays
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [Patch 00/17] Autorebuild
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH] md: Call blk_queue_flush() to establish flush/fua support
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: Autorebuild, new dynamic udev rules for hot-plugs
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Devel 3.2 branch issues
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Autorebuild, new dynamic udev rules for hot-plugs
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH] md: Call blk_queue_flush() to establish flush/fua support
  • From: Neil Brown <neilb@xxxxxxx>
• RE: Autorebuild, new dynamic udev rules for hot-plugs
  • From: "Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@xxxxxxxxx>
• Superblocks out-of-sync on a RAID5 array
  • From: Michał Sawicz <michal@xxxxxxxxxx>
• [PATCH] md: Call blk_queue_flush() to establish flush/fua support
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• RE: Devel 3.2 branch issues
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: Devel 3.2 branch issues
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• RE: Devel 3.2 branch issues
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• RE: [Patch 00/17] Autorebuild
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: [PATCH] md: Fix nr_pending race during raid10 recovery
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Autorebuild, new dynamic udev rules for hot-plugs
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Array read 3 time slower to read after data fully loaded
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Boot from degraded MD array
  • From: Neil Brown <neilb@xxxxxxx>
• Re: faulty array member
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Devel 3.2 branch issues
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [Patch 00/17] Autorebuild
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Device state during an incremental assembly
  • From: Wakko Warner <wakko@xxxxxxxxxxxx>
• Re: Device state during an incremental assembly
  • 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: Device state during an incremental assembly
  • From: Wakko Warner <wakko@xxxxxxxxxxxx>
• Re: Device state during an incremental assembly
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Device state during an incremental assembly
  • From: Wakko Warner <wakko@xxxxxxxxxxxx>
• Re: Device state during an incremental assembly
  • From: Neil Brown <neilb@xxxxxxx>
• Re: raid6 failed due to loss of connection
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Device state during an incremental assembly
  • From: Wakko Warner <wakko@xxxxxxxxxxxx>
• Re: bug in bio_map_user_iov
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Autorebuild, new dynamic udev rules for hot-plugs
  • From: "Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@xxxxxxxxx>
• raid6 failed due to loss of connection
  • From: Björn Englund <be@xxxxxxxxxxx>
• Devel 3.2 branch issues
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: faulty array member
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Help! I killed my mdadm raid 5
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [dm-devel] [RFC] training mpath to discern between SCSI errors
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• RE: Help! I killed my mdadm raid 5
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• RE: [Patch 00/17] Autorebuild
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: Help! I killed my mdadm raid 5 - more info I should have included
  • From: <p3-500@xxxxxxxxxxxxxx>
• Re: bug in bio_map_user_iov
  • From: Michael Demmer <Michael.Demmer@xxxxxxxxxxxx>
• RE: Array read 3 time slower to read after data fully loaded
  • From: David Lethe <david@xxxxxxxxxxxx>
• Re: Array read 3 time slower to read after data fully loaded
  • From: Michal Soltys <soltys@xxxxxxxx>
• Help! I killed my mdadm raid 5
  • From: <p3-500@xxxxxxxxxxxxxx>
• Re: faulty array member
  • From: Tim Small <tim@xxxxxxxxxxxxxxxx>
• faulty array member
  • From: Roberto Nunnari <roberto.nunnari@xxxxxxxx>
• 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: Boot from degraded MD array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Boot from degraded MD array
  • From: "G, Sushma" <Sushma.G@xxxxxxx>
• [PATCH 13/13] External reshape (step 2): Freeze container
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 12/13] External reshape (step 1): container reshape and ->reshape_super()
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 11/13] Document the external reshape implementation
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 10/13] Initialize st->devnum and st->container_dev in super_by_fd
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 09/13] Create: cleanup/unify default geometry handling
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 08/13] fix a get_linux_version() comparison typo
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 07/13] Grow: add missing raid4 geometries to geo_map()
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 06/13] Grow: fix check for raid6 layout normalization
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 05/13] Assemble: fix assembly in the delta_disks > max_degraded case
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 04/13] Grow: mark some functions static
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 03/13] Manage: allow manual control of external raid0 readonly flag
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 02/13] block monitor: freeze spare assignment for external arrays
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 01/13] Provide a mdstat_ent to subarray helper
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• [PATCH 00/13] Series short description
  • From: Krzysztof Wojcik <krzysztof.wojcik@xxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• Array read 3 time slower to read after data fully loaded
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• Re: bug in bio_map_user_iov
  • From: Neil Brown <neilb@xxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• bug in bio_map_user_iov
  • From: Michael Demmer <Michael.Demmer@xxxxxxxxxxxx>
• [PATCH] md: Fix nr_pending race during raid10 recovery
  • From: Aniket Kulkarni <aniket@xxxxxxxxxxx>
• RE: [Patch 00/17] Autorebuild
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• Re: [Patch 00/17] Autorebuild
  • From: Neil Brown <neilb@xxxxxxx>
• Re: mdadm raid6->LVM->ext4 setup
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Neil Brown <neilb@xxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Neil Brown <neilb@xxxxxxx>
• RE: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: mdadm raid6->LVM->ext4 setup
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: mdadm raid6->LVM->ext4 setup
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: mdadm raid6->LVM->ext4 setup
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Re: mdadm raid6->LVM->ext4 setup
  • From: Roman Mamedov <roman@xxxxxxxx>
• mdadm raid6->LVM->ext4 setup
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• RE: [RFC][PATCH] md: force full sync when adding the wrong device to a mirror
  • From: "Dailey, Nate" <Nate.Dailey@xxxxxxxxxxx>
• Re: md raid1 rebuild bug? (2.6.32.25)
  • From: Sebastian Färber <faerber@xxxxxxxxx>
• Re: read errors (in superblock?) aren't fixed by md?
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• AW: raid5 to raid6 reshape - power loss - does not assemble any more
  • From: Aussie <aussie_1968@xxxxxxxxx>
• Re: [RFC][PATCH] md: force full sync when adding the wrong device to a mirror
  • From: Neil Brown <neilb@xxxxxxx>
• [RFC][PATCH] md: force full sync when adding the wrong device to a mirror
  • From: "Nate Dailey" <nate.dailey@xxxxxxxxxxx>
• Re: raid5 to raid6 reshape - power loss - does not assemble any more
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Superblock V 1.2
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Superblock V 1.2
  • From: Martin Cracauer <cracauer@xxxxxxxx>
• Re: Superblock V 1.2
  • From: Neil Brown <neilb@xxxxxxx>
• Re: ata4.00: exception Emask 0x0 SAct 0x1b7ffff SErr 0x0 action 0x6 frozen
  • From: Jeff Garzik <jeff@xxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Re: Superblock V 1.2
  • From: Martin Cracauer <cracauer@xxxxxxxx>
• Re: ata4.00: exception Emask 0x0 SAct 0x1b7ffff SErr 0x0 action 0x6 frozen
  • From: Tim Small <tim@xxxxxxxxxxx>
• ata4.00: exception Emask 0x0 SAct 0x1b7ffff SErr 0x0 action 0x6 frozen
  • From: Pol Hallen <raid2@xxxxxxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• raid5 to raid6 reshape - power loss - does not assemble any more
  • From: Aussie <aussie_1968@xxxxxxxxx>
• Re: When does the raid bitmap actually work.
  • From: Daniel Reurich <daniel@xxxxxxxxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Suggestion for rebuilding my raids?
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• Re: [PATCH 15/17] Monitor: more accurate size check when looking for spares
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: When does the raid bitmap actually work.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Help!
  • From: Neil Brown <neilb@xxxxxxx>
• Re: sw raid5 hungs on resync and high IO load, 2.6.32.23
  • From: Neil Brown <neilb@xxxxxxx>
• Re: md raid1 rebuild bug? (2.6.32.25)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Superblock V 1.2
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH] md: fix return value of rdev_size_change()
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Luca Berra <bluca@xxxxxxxxxx>
• Re: Confusion with setting up new RAID6 with mdadm
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Confusion with setting up new RAID6 with mdadm
  • From: Zoltan Szecsei <zoltans@xxxxxxxxxxxxxx>
• How to recreate a dmraid RAID array with mdadm (was: no subject)
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re:
  • From: Neil Brown <neilb@xxxxxxx>
• [no subject]
  • From: Mike Viau <viaum@xxxxxxxxxxxxxxx>
• Re: read errors (in superblock?) aren't fixed by md?
  • From: Neil Brown <neilb@xxxxxxx>
• read errors (in superblock?) aren't fixed by md?
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: [PATCH] md: fix return value of rdev_size_change()
  • From: Justin Maggard <jmaggard10@xxxxxxxxx>
• [PATCH] md: fix return value of rdev_size_change()
  • From: Justin Maggard <jmaggard10@xxxxxxxxx>
• Re: [PATCH 15/17] Monitor: more accurate size check when looking for spares
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Superblock V 1.2
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• [PATCH] md: raid5: update suspend_hi during the reshape
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 11/31] imsm: Verify slots in meta against slot numbers set by md
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 12/31] imsm: Cancel metadata changes on reshape start failure
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 29/31] mdadm: migration restart for external meta
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 23/31] mdadm: second_map enhancement for imsm_get_map()
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 19/31] Prepare and free fdlist in functions
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 28/31] mdadm: support backup operations for imsm
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 30/31] Add mdadm->mdmon sync_max command message
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 22/31] Finalize reshape after adding disks to array
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 26/31] mdadm: add backup methods to superswitch
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 27/31] mdadm: support restore_stripes() from the given buffer
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 14/31] imsm: Do not indicate resync during reshape
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 20/31] Compute backup blocks in function.
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 24/31] mdadm: read chunksize and layout from mdstat
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 25/31] mdadm: Add IMSM migration record to intel_super
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 15/31] Add spares to raid0 array using takeover
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 21/31] Control reshape in mdadm
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 18/31] imsm: FIX: spare list contains one device several times
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 16/31] imsm: FIX: Fill sys_name field in getinfo_super()
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 17/31] imsm: FIX: Fill delta_disks field in getinfo_super()
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 13/31] imsm: Do not accept messages sent by mdadm
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 08/31] Send information to managemon about reshape request
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 10/31] Add support to skip slot configuration
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 07/31] imsm: FIX: core dump during imsm metadata writing
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 04/31] Treat feature as experimental
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 03/31] FIX: allow for execution for new size set to 0
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 02/31] Disk removal support for Raid10->Raid0 takeover
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 01/31] Add takeover support for external meta
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 00/31] Add Online Capacity Expansion with checkpointing to mdadm for external metadata
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 09/31] Process reshape initialization by managemon
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 06/31] imsm: Add reshape_update for grow array case
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 05/31] imsm: Add support for general migration
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• [PATCH 31/31] mdadm: support grow operation for external meta
  • From: "Kwolek, Adam" <adam.kwolek@xxxxxxxxx>
• Re: Superblock V 1.2
  • From: Martin Cracauer <cracauer@xxxxxxxx>
• RE: [PATCH 15/17] Monitor: more accurate size check when looking for spares
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• md raid1 rebuild bug? (2.6.32.25)
  • From: Sebastian Färber <faerber@xxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: "Mr. James W. Laferriere" <babydr@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Superblock V 1.2
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Andreas Dröscher <raid@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Superblock V 1.2
  • From: Martin Cracauer <cracauer@xxxxxxxx>
• RE: Superblock V 1.2
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Roman Mamedov <roman@xxxxxxxx>
• RE: Determining which spindle is out of order
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Superblock V 1.2
  • From: Martin Cracauer <cracauer@xxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Jan Ceuleers <jan.ceuleers@xxxxxxxxxxxx>
• RE: Determining which spindle is out of order
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: "Mr. James W. Laferriere" <babydr@xxxxxxxxxxxxxxxx>
• RE: Determining which spindle is out of order
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Jan Ceuleers <jan.ceuleers@xxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• RE: Determining which spindle is out of order
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: [PATCH 09/17] Monitor: avoid skipping checks on external arays
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• RE: [PATCH 09/17] Monitor: avoid skipping checks on external arays
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: [PATCH 16/17] IMSM: Fix problem in mdmon monitor of using removed disk from in imsm container.
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 15/17] Monitor: more accurate size check when looking for spares
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 13/17] Monitor: autorebuild functionality added
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 12/17] imsm: create mdinfo list of disks in a container from supertype
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 09/17] Monitor: avoid skipping checks on external arays
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 05/17] Util: get device size from id
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 03/17] extension of IncrementalRemove to store location (path-id) of removed device
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 14/49] drivers/md: Use vzalloc
  • From: Joe Perches <joe@xxxxxxxxxxx>
• RE: Upgraded grub, now confused about mirrored /boot
  • From: "Guy Watkins" <linux-raid@xxxxxxxxxxxxxxxx>
• Re: mdadm / RAID, a few questions
  • From: Mathias Burén <mathias.buren@xxxxxxxxx>
• Re: status of sas1068 ata-passthrough bug?
  • From: Vincent Schut <schut@xxxxxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Tom Carlson <twigathy@xxxxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: Samsung F1 RAID Class SATA/300 1TB drives
  • From: Bill Davidsen <davidsen@xxxxxxx>
• Re: Determining which spindle is out of order
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Jon Hardcastle <jonathan.hardcastle@xxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• RE: Determining which spindle is out of order
  • From: "Graham Mitchell" <gmitch@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: Determining which spindle is out of order
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: Determining which spindle is out of order
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Determining which spindle is out of order
  • From: Nat Makarevitch <Shelso@xxxxxxxxxxxxxxx>
• 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: 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>