Linux RAID Storage Date Index

• Thread Index

• [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>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: [dm-devel] [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Sergey Vlasov <vsu@xxxxxxxxxxx>
• Re: [dm-devel] [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: [RFC PATCHSET block#for-2.6.36-post] block: convert to REQ_FLUSH/FUA
  • From: Christoph Hellwig <hch@xxxxxx>
• OT grammar nit Re: [PATCH] block: simplify queue_next_fseq
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] block: simplify queue_next_fseq
  • From: Christoph Hellwig <hch@xxxxxx>
• 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: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• 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: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH v2] BLOCK: fix bio.bi_rw handling
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: mdadm create problem with existing bitmap file
  • From: Neil Brown <neilb@xxxxxxx>
• raid hung due to a drive failure during reshape
  • From: Anssi Hannula <anssi.hannula@xxxxxx>
• Re: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• RE: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: gabe peters <gabe.peters@xxxxxxxxx>
• mdadm create problem with existing bitmap file
  • From: Juan Aristizabal <jaristizabal@xxxxxxxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• RE: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• RE: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• Re: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• RE: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• Re: question on how to update the super-minor
  • From: Neil Brown <neilb@xxxxxxx>
• question on how to update the super-minor
  • From: Joe Landman <landman@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• RE: getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 3/5] lguest: replace VIRTIO_F_BARRIER support with VIRTIO_F_FLUSH support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 2/5 UPDATED] virtio_blk: drop REQ_HARDBARRIER support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• 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: Christoph Hellwig <hch@xxxxxx>
• 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: Tejun Heo <tj@xxxxxxxxxx>
• Re: [dm-devel] [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• getting a linux boot loader (preferably grub) installed on an intel imsm raid
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• 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: Vladislav Bolkhovitin <vst@xxxxxxxx>
• Re: intel fakeraid (imsm) linux kernel support
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <teheo@xxxxxxx>
• 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: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 08/11] block: rename barrier/ordered to flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PULL REQUEST] a few fixes for md.
  • From: Neil Brown <neilb@xxxxxxx>
• the true behavior of mdadm's raid-1 with regard to vertical parity and silent error detection/scrubbing- confirmation or feature request
  • From: "Brett L. Trotter" <brett@xxxxxxxxxx>
• Re: mdadm: too-old timestamp on backup-metadata
  • From: William Heaton <acroporas@xxxxxxxxx>
• Re: mdadm: too-old timestamp on backup-metadata
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
• Re: [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• [BUG raid1] kernel BUG at drivers/scsi/scsi_lib.c:1113
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
• Re: reboot during reshape: superblock incorrect, cannot assemble
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: reboot during reshape: superblock incorrect, cannot assemble
  • From: Joris <joris@xxxxx>
• Re: reboot during reshape: superblock incorrect, cannot assemble
  • From: Joris <joris@xxxxx>
• Re: reboot during reshape: superblock incorrect, cannot assemble
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• reboot during reshape: superblock incorrect, cannot assemble
  • From: Joris <joris@xxxxx>
• mdadm: too-old timestamp on backup-metadata
  • From: William Heaton <acroporas@xxxxxxxxx>
• RE: [mdadm git pull] "--assemble --scan" support for imsm
  • From: "Jiang, Dave" <dave.jiang@xxxxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: intel fakeraid (imsm) linux kernel support
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 08/11] block: rename barrier/ordered to flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [mdadm git pull] "--assemble --scan" support for imsm
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 08/11] block: rename barrier/ordered to flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• intel fakeraid (imsm) linux kernel support
  • From: "K. Posern" <quickhelp@xxxxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• mdadm -C failure with 3.1.3, but /proc/mdstat reports success
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: [PATCH 08/11] block: rename barrier/ordered to flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [patch 1/6] md: remove dependency on __GFP_NOFAIL
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 1/5] block/loop: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 3/5] lguest: replace VIRTIO_F_BARRIER support with VIRTIO_F_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [RFC PATCHSET block#for-2.6.36-post] block: convert to REQ_FLUSH/FUA
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 4/5] md: implment REQ_FLUSH/FUA support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH UPDATED 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Nicolas Jungers <nicolas@xxxxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• [PATCH 34/35] Incremental for bare disks, checking routine + integration
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 35/35] Fix problem in mdmon monitor of using removed disk from in imsm container.
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 33/35] update udev rules to support --path parameter with remove action
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 32/35] extension of IncrementalRemove to store location (port) of removed device
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 31/35] added --path <path_id> to give the information on the 'path-id' of removed device
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 30/35] Man pages update with DOMAIN line description.
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 28/35] Monitor: added spare sharing and dev suitable functions
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 29/35] Monitor: autorebuild funcionality added
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 27/35] Monitor: added function move_spare
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 26/35] Monitor: get array domain and subset function added
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 25/35] Monitor: fill devstate of containers based on supertype
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 24/35] imsm: create mdinfo list of disks in a container from supertype
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 23/35] Monitor: link container-volumes in statelist
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 22/35] mdadm: added --no-sharing parameter for Monitor mode
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 21/35] Monitor: removed spare-group based spare sharing code
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 20/35] Monitor: set err on arrays not in mdstat
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 19/35] Util: get device size from id
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 18/35] Assemble: assembly with domains - two runs for imsm spares
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 17/35] Removed uuid setting for imsm spares
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 16/35] test code for loop device support added
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 15/35] additional environment dependent code for platform subset tests
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 14/35] incremental: add domain/subset support
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 13/35] manage: domains support in Manage_subdev
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 12/35] create: respect domains/subsets during create process
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 11/35] assembly: user domain/subset from configuration file in assembly process
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 08/35] imsm: platform dependent domain boundaries
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 07/35] add general domain/subset lists manipulation routines
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 06/35] Updates to udev rules and ReadMe.c for incremental --grab support
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 10/35] update domain search to new structures, added subset search
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 09/35] processing of domain entries made after config is loaded
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 05/35] Partition action support in DOMAIN line
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 04/35] Support for new disk hot plug actions with DOMAINs.
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 03/35] Config option parsing for new DOMAIN line support
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 02/35] Few fixes and sample udev rules file to capture block devices
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 01/35] [hotunplug] we are testing mdstat, not ent which is undefined at this
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• [PATCH 0/35] Autorebuild updated
  • From: "Czarnowska, Anna" <anna.czarnowska@xxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: Neil Brown <neilb@xxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Nicolas Jungers <nicolas@xxxxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Nicolas Jungers <nicolas@xxxxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• Re: RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• RAID5 disk failure during rebuild of spare, any chance of recovery when one of the failed devices is suspected to be intact?
  • From: Tor Arne Vestbø <torarnv@xxxxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Pro-active replacement
  • From: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
• Problem with raid in QNAP TS-639Pro
  • From: Pavel Pilný <pavel@xxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• 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: Christoph Hellwig <hch@xxxxxx>
• 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: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG
  • 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: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
  • From: Jan Kara <jack@xxxxxxx>
• Boot md/udev event storm
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [PATCH v2] BLOCK: fix bio.bi_rw handling
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: [PATCH v2] BLOCK: fix bio.bi_rw handling
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v2] MD: raid, fix BUG caused by flags handling
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v2] SCSI: fix bio.bi_rw handling
  • From: Christoph Hellwig <hch@xxxxxx>
• RE: A policy frame work for mdadm (incorporating domains and hotplug and such)
  • From: "Labun, Marcin" <Marcin.Labun@xxxxxxxxx>
• Re: [PATCH v2] BLOCK: fix bio.bi_rw handling
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH v2] SCSI: fix bio.bi_rw handling
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH v2] MD: raid, fix BUG caused by flags handling
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• [PATCH 05/11] block: misc cleanups in barrier code
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 01/11] block/loop: queue ordered mode should be DRAIN_FLUSH
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 09/11] block: implement REQ_FLUSH/FUA based interface for FLUSH/FUA requests
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 07/11] block: rename blk-barrier.c to blk-flush.c
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 08/11] block: rename barrier/ordered to flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 11/11] block: use REQ_FLUSH in blkdev_issue_flush()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 03/11] block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 04/11] block: remove spurious uses of REQ_HARDBARRIER
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 06/11] block: drop barrier ordering by queue draining
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH v2] BLOCK: fix bio.bi_rw handling
  • From: Jiri Slaby <jslaby@xxxxxxx>
• [PATCH v2] MD: raid, fix BUG caused by flags handling
  • From: Jiri Slaby <jslaby@xxxxxxx>
• [PATCH v2] SCSI: fix bio.bi_rw handling
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: [PATCH] MD: raid1, fix BUG caused by flags handling
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• [PATCH] MD: raid1, fix BUG caused by flags handling
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: weird SparesMissing event
  • From: Tobias Gunkel <tobias.gunkel@xxxxxxxxx>
• Re: [mdadm PATCH 0/2] two 3.1.3 regression fixes (incremental assembly)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [mdadm PATCH 0/2] two 3.1.3 regression fixes (incremental assembly)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Fw: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Stefan /*St0fF*/ Hübner <stefan.huebner@xxxxxxxxxxxxxxxxxx>
• Re: [REVISED PULL REQUEST] md updates for 2.6.36
  • From: Neil Brown <neilb@xxxxxxx>
• Re: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Neil Brown <neilb@xxxxxxx>
• Re: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: weird SparesMissing event
  • From: Neil Brown <neilb@xxxxxxx>
• Re: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Neil Brown <neilb@xxxxxxx>
• Sorry if Spamming! - sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Re: weird SparesMissing event
  • From: Tobias Gunkel <tobias.gunkel@xxxxxxxxx>
• Re: debian dist-upgrade etch -> squeeze broke my mdadm RAID1
  • From: Tim Small <tim@xxxxxxxxxxx>
• Re: weird SparesMissing event
  • From: Neil Brown <neilb@xxxxxxx>
• weird SparesMissing event
  • From: Tobias Gunkel <tobias.gunkel@xxxxxxxxx>
• debian dist-upgrade etch -> squeeze broke my mdadm RAID1
  • From: Doug <doug.duboulay@xxxxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [mdadm PATCH 0/2] two 3.1.3 regression fixes (incremental assembly)
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [REVISED PULL REQUEST] md updates for 2.6.36
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [REVISED PULL REQUEST] md updates for 2.6.36
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Fw: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• Fw: sdc1 does not have a valid v0.90 superblock, not importing!
  • From: Jon Hardcastle <jd_hardcastle@xxxxxxxxx>
• [mdadm PATCH 2/2] Incremental: accept '--no-degraded' as a deprecated option
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [mdadm PATCH 1/2] Incremental: return success in 'container not enough' case
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [mdadm PATCH 0/2] two 3.1.3 regression fixes (incremental assembly)
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [REVISED PULL REQUEST] md updates for 2.6.36
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH REPOST RFC] relaxed barriers
  • From: Tejun Heo <teheo@xxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: Neil Brown <neilb@xxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: Neil Brown <neilb@xxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: Problem regarding RAID10 on kernel 2.6.31
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Problem regarding RAID10 on kernel 2.6.31
  • From: ravichandra <vmynidi@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] md: move revalidate_disk() back outside open_mutex
  • From: Neil Brown <neilb@xxxxxxx>
• cciss_vol_status can't decide if it has a broken array or not
  • From: Tomasz Chmielewski <tch@xxxxxxxx>
• Re: [PATCH REPOST RFC] relaxed barriers
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• RE: --assume-clean on raid5/6
  • From: <brian.foster@xxxxxxx>
• [PULL REQUEST] md updates for 2.6.36
  • From: Neil Brown <neilb@xxxxxxx>
• Re: md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: Neil Brown <neilb@xxxxxxx>
• Re: --assume-clean on raid5/6
  • From: Neil Brown <neilb@xxxxxxx>
• md's fail to assemble correctly consistently at system startup - mdadm 3.1.2 and Ubuntu 10.04
  • From: "fibreraid@xxxxxxxxx" <fibreraid@xxxxxxxxx>
• Re: --assume-clean on raid5/6
  • From: Stefan /*St0fF*/ Hübner <stefan.huebner@xxxxxxxxxxxxxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH REPOST RFC] relaxed barriers
  • From: Tejun Heo <teheo@xxxxxxx>
• [PATCH] md: move revalidate_disk() back outside open_mutex
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH, RFC] relaxed barriers
  • From: Christoph Hellwig <hch@xxxxxx>
• RE: raid1: prevent adding a "too recent" device to a mirror?
  • From: "Dailey, Nate" <Nate.Dailey@xxxxxxxxxxx>
• Re: [PATCH, RFC] relaxed barriers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.3 - A tool for managing Soft RAID under Linux
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Problem regarding RAID10 on kernel 2.6.31
  • From: Neil Brown <neilb@xxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.3 - A tool for managing Soft RAID under Linux
  • From: Neil Brown <neilb@xxxxxxx>
• Problem regarding RAID10 on kernel 2.6.31
  • From: ravichandra <vmynidi@xxxxxxxxxxxxxxxxxx>
• Re: ANNOUNCE: mdadm 3.1.3 - A tool for managing Soft RAID under Linux
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• ANNOUNCE: mdadm 3.1.3 - A tool for managing Soft RAID under Linux
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tao Ma <tao.ma@xxxxxxxxxx>
• --assume-clean on raid5/6
  • From: <brian.foster@xxxxxxx>
• Performance impact of CONFIG_SCHED_MC? direct-io test case
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Performance impact of CONFIG_DEBUG? direct-io test case
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Vladislav Bolkhovitin <vst@xxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• RE: Replacing a drive in RAID 0
  • From: Ben Nemec <lists@xxxxxxxxxxxx>
• Strange initramfs+udev+raid interaction creating /dev/md/*
  • From: Michael Guntsche <mike@xxxxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Josef Bacik <josef@xxxxxxxxxx>
• Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• RE: Replacing a drive in RAID 0
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Neil Brown <neilb@xxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Valdis.Kletnieks@xxxxxx
• Re: mdadm 3.1.x and bitmap chunk
  • From: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
• Strange initramfs+udev+raid interaction creating /dev/md/*
  • From: Michael Guntsche <mike@xxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
• Re: mdadm 3.1.x and bitmap chunk
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• Re: when does a raid rebuild failed
  • From: Drew <drew.kay@xxxxxxxxx>
• Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH, RFC 1/2] relaxed cache flushes
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: mdadm 3.1.x and bitmap chunk
  • From: Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx>
• Re: [PATCH] coda: rename REQ_* to CODA_REQ_*
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH] coda: rename REQ_* to CODA_REQ_*
  • From: Jan Harkes <jaharkes@xxxxxxxxxx>
• [PATCH] coda: rename REQ_* to CODA_REQ_*
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• when does a raid rebuild failed
  • From: 邹勇波 <zou.yongbo@xxxxxxxxx>
• Re: Replacing a drive in RAID 0
  • From: Ben Nemec <lists@xxxxxxxxxxxx>
• Re: [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Jens Axboe <axboe@xxxxxxxxx>
• [PATCH 2/2 block#for-2.6.36] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: Replacing a drive in RAID 0
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Replacing a drive in RAID 0
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: Replacing a drive in RAID 0
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Replacing a drive in RAID 0
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Replacing a drive in RAID 0
  • From: Ben Nemec <lists@xxxxxxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Justin Bronder <jsbronder@xxxxxxxxxx>
• Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: mdadm 3.1.x and bitmap chunk
  • From: Doug Ledford <dledford@xxxxxxxxxx>
• [PATCH RESEND 2/2 block#for-linus] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH RESEND 2/2 block#for-linus] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 2/2 block#for-linus] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: sw raid array completely hungs during verify in 2.6.32
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: RAID/block regression starting from 2.6.32, bisected
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH]md:dm.c Fix warning: statement with no effect
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• failed to re-assemble after cable-problem...
  • From: wiebittewas <wiebittewas@xxxxxxxxxxxxxx>
• sw raid array completely hungs during verify in 2.6.32
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• Re: [PATCH]md:dm.c Fix warning: statement with no effect
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: [PATCH]md:dm.c Fix warning: statement with no effect
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH]md:dm.c Fix warning: statement with no effect
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: raid1 performance
  • From: Keld Simonsen <keld@xxxxxxxxxx>
• Re: raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• Re: RAID/block regression starting from 2.6.32, bisected
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: Pending sectors in valid array - how to proceed?
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: MD raid and different elevators (disk i/o schedulers)
  • From: Fabio Muzzi <liste@xxxxxxxxxx>
• Re: MD raid and different elevators (disk i/o schedulers)
  • From: Eric Shubert <ejs@xxxxxxxxxx>
• Re: MD raid and different elevators (disk i/o schedulers)
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• MD raid and different elevators (disk i/o schedulers)
  • From: Fabio Muzzi <liste@xxxxxxxxxx>
• Re: Pending sectors in valid array - how to proceed?
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: Pending sectors in valid array - how to proceed?
  • From: Simon Matthews <simon.d.matthews@xxxxxxxxx>
• Re: Pending sectors in valid array - how to proceed?
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: Pending sectors in valid array - how to proceed?
  • From: Stefan *St0fF* Huebner <st0ff@xxxxxxx>
• Endian issue assembling arrays
  • From: Doug Nazar <nazard.michi@xxxxxxxxx>
• Re: md versus partition scanning (bd_invalidated)
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Pending sectors in valid array - how to proceed?
  • From: Tim Small <tim@xxxxxxxxxxx>
• RAID/block regression starting from 2.6.32, bisected
  • From: Vladislav Bolkhovitin <vst@xxxxxxxx>
• Pending sectors in valid array - how to proceed?
  • From: "Stefan G. Weichinger" <lists@xxxxxxxx>
• Re: raid1 performance
  • From: Neil Brown <nfbrown@xxxxxxxxxx>
• Re: raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• Re: Software raid-5 on root partition (2.6.32.1)
  • From: Kurt Newman <knewman@xxxxxxxxxxxxxxxxxxx>
• Software raid-5 on root partition (2.6.32.1)
  • From: Kurt Newman <knewman@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] md: bitwise operations might not fit in a "bool"
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: raid1 performance
  • From: Neil Brown <nfbrown@xxxxxxxxxx>
• Re: A policy frame work for mdadm (incorporating domains and hotplug and such)
  • From: Neil Brown <neilb@xxxxxxx>
• RE: A policy frame work for mdadm (incorporating domains and hotplug and such)
  • From: "Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@xxxxxxxxx>
• Re: raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• Re: raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• Re: Increase request size for levels other than raid0?
  • From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxx>
• RE: raid1 performance
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• [PATCH] Notify sysfs when RAID1 disk is In_sync.
  • From: Adrian Drzewiecki <adriand@xxxxxxxxxx>
• rw-mount necessary while assemble?
  • From: wiebittewas <wiebittewas@xxxxxxxxxxxxxx>
• Increase request size for levels other than raid0?
  • From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxx>
• Re: raid1 performance
  • From: Keld Simonsen <keld@xxxxxxxxxx>
• Re: raid1 performance
  • From: Neil Brown <nfbrown@xxxxxxxxxx>
• Re: raid1 performance
  • From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
• Re: raid1 performance
  • From: Keld Simonsen <keld@xxxxxxxxxx>
• Re: raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• [PATCH 8/8] dm-raid456: switch to use dm_dirty_log for tracking dirty regions.
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 7/8] dm-dirty-log: allow log size to be different from target size.
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 6/8] dm-raid456: add message handler.
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 5/8] dm-raid456: add suspend/resume method
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 4/8] dm-raid456: add support for setting IO hints.
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 3/8] dm-raid456: support unplug
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 2/8] dm-raid456: add congestion checking.
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 1/8] md/dm: create dm-raid456 module using md/raid5
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• [PATCH 0/8] The DM part of dm-raid45
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• Re: raid1 performance
  • From: Roman Mamedov <roman@xxxxxxxx>
• raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• RE: [PATCH] Adding ADMA support for PPC460EX DMA engine.
  • From: Tirumala Marri <tmarri@xxxxxxx>
• Re: [PATCH] Adding ADMA support for PPC460EX DMA engine.
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Justin Bronder <jsbronder@xxxxxxxxxx>
• Stripe Cache
  • From: Chris Farey <chris@xxxxxxxxx>
• Re: [PATCH] Adding ADMA support for PPC460EX DMA engine.
  • From: Stefan Roese <sr@xxxxxxx>
• Re: raid1: prevent adding a "too recent" device to a mirror?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Raid10 device hangs during resync and heavy I/O.
  • From: Justin Bronder <jsbronder@xxxxxxxxxx>
• raid1: prevent adding a "too recent" device to a mirror?
  • From: "Dailey, Nate" <Nate.Dailey@xxxxxxxxxxx>
• Re: Why is sb->size set to 0 with raid0?
  • From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxx>
• Re: Why is sb->size set to 0 with raid0?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Why is sb->size set to 0 with raid0?
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: [PATCH] md: bitwise operations might not fit in a "bool"
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH] md: bitwise operations might not fit in a "bool"
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [PATCH] md: bitwise operations might not fit in a "bool"
  • From: Neil Brown <neilb@xxxxxxx>
• [PATCH] md: bitwise operations might not fit in a "bool"
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: Why is sb->size set to 0 with raid0?
  • From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxx>
• Re: BUG REPORT: md RAID5 write throughput will drop for 1~2s every 16s (under 1Hz sample rate)
  • From: Eddy Zhao <eddy.y.zhao@xxxxxxxxx>
• Re: BUG at drivers/scsi/scsi_lib.c:1113
  • From: Boaz Harrosh <openosd@xxxxxxxxx>
• RE: [PATCH 1/2] md: raid5 return new layout in mdstat while reshaping
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• Re: BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: BUG at drivers/scsi/scsi_lib.c:1113
  • From: Christoph Hellwig <hch@xxxxxx>
• RE: [PATCH 0/2] md: migrations for external metadata
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• Re: BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: fixes for 3.1.3 (was: Re: [mdadm GIT PULL] rebuild checkpoints...)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: BUG at drivers/scsi/scsi_lib.c:1113
  • From: Neil Brown <neilb@xxxxxxx>
• BUG at drivers/scsi/scsi_lib.c:1113
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: Why is sb->size set to 0 with raid0?
  • From: Neil Brown <neilb@xxxxxxx>
• Re: [PATCH 1/2] md: raid5 return new layout in mdstat while reshaping
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: help needed - 4 disk raid4 with two missing disks
  • From: Rainer Fuegenstein <rfu@xxxxxxxxxxxxxxxxxxxxxxxx>
• md versus partition scanning (bd_invalidated)
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: fixes for 3.1.3 (was: Re: [mdadm GIT PULL] rebuild checkpoints...)
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/2] md: migrations for external metadata
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Why is sb->size set to 0 with raid0?
  • From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxx>
• Re: help needed - 4 disk raid4 with two missing disks
  • From: Keld Simonsen <keld@xxxxxxxxxx>
• help needed - 4 disk raid4 with two missing disks
  • From: Rainer Fuegenstein <rfu@xxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 10/10] mdadm: migration restart for external meta
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 08/10] mdadm: support backup operations for imsm
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 09/10] mdadm: support grow operation for external meta
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 07/10] Add mdadm->mdmon sync_max command message
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 06/10] mdadm: support restore_stripes() from the given buffer
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 05/10] mdadm: add backup methods to superswitch
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 04/10] mdadm: Add IMSM migration record to intel_super
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 03/10] mdadm: support non-grow reshape for external meta
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 02/10] mdadm: read chunksize and layout from mdstat
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 00/10] mdadm: reshape for external metadata
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 01/10] mdadm: second_map enhancement for imsm_get_map()
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 2/2] md: raid5: update suspend_hi during the reshape
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 1/2] md: raid5 return new layout in mdstat while reshaping
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• [PATCH 0/2] md: migrations for external metadata
  • From: "Trela, Maciej" <Maciej.Trela@xxxxxxxxx>
• RE: Changing Chunk Size on Array
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• RE: RAID10 status when you remove the first disk and last disk
  • From: "Michael Li" <michael.li@xxxxxxxxxxx>
• Re: RAID10 status when you remove the first disk and last disk
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Missing Drives
  • From: Miles Fidelman <mfidelman@xxxxxxxxxxxxxxxx>
• Re: Missing Drives
  • From: Mark Knecht <markknecht@xxxxxxxxx>
• Missing Drives
  • From: James Howells <james@xxxxxxxxxxxxxx>
• Re: [SOLVED] Re: messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• minor typo in md.txt
  • From: William Stearns <wstearns@xxxxxxxxx>
• [SOLVED] Re: messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• Re: mdadm "hang", 100% CPU usage when trying to create RAID-1 array with external bitmap
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: BUG REPORT: md RAID5 write throughput will drop for 1~2s every 16s (under 1Hz sample rate)
  • From: Neil Brown <neilb@xxxxxxx>
• Re: messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• Re: messed up changing chunk size
  • From: Konstantin Svist <kostya@xxxxxxxxxxx>
• Re: Changing Chunk Size on Array
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• Re: Changing Chunk Size on Array
  • From: Neil Brown <neilb@xxxxxxx>
• Re: mdadm "hang", 100% CPU usage when trying to create RAID-1 array with external bitmap
  • From: Neil Brown <neilb@xxxxxxx>
• Re: messed up changing chunk size
  • From: Keld Simonsen <keld@xxxxxxxxxx>
• Re: messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• Re: messed up changing chunk size
  • From: Roman Mamedov <roman@xxxxxxxx>
• Re: messed up changing chunk size
  • From: Jools Wills <jools@xxxxxxxxxxxxxxxxxxx>
• raid1 performance
  • From: Marco <jjletho67-diar@xxxxxxxx>
• Re: messed up changing chunk size
  • From: Roman Mamedov <roman@xxxxxxxx>
• RE: messed up changing chunk size
  • From: "Guy Watkins" <linux-raid@xxxxxxxxxxxxxxxx>
• Re: messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• RE: messed up changing chunk size
  • From: "Guy Watkins" <linux-raid@xxxxxxxxxxxxxxxx>
• RE: messed up changing chunk size
  • From: "Steven Haigh" <netwiz@xxxxxxxxx>
• Re: messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• messed up changing chunk size
  • From: Konstantin Svist <fry.kun@xxxxxxxxx>
• Re: mdadm "hang", 100% CPU usage when trying to create RAID-1 array with external bitmap
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• RE: Grow error - WTF!?
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: Grow error - WTF!?
  • From: Jérôme Poulin <jeromepoulin@xxxxxxxxx>
• RE: Changing Chunk Size on Array
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Grow error - WTF!?
  • From: "Leslie Rhorer" <lrhorer@xxxxxxxxxxx>
• Re: Changing Chunk Size on Array
  • From: Roman Mamedov <roman@xxxxxxxx>