Linux RAID Storage Date Index

• Thread Index

• Re: best way to replace all disks
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Julien ROBIN <julien.robin28@xxxxxxx>
• Re: WARNING: CPU: 13 PID: 3786 at drivers/md/raid5.c:4611 break_stripe_batch_list+0x86/0x1fb
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• WARNING: CPU: 13 PID: 3786 at drivers/md/raid5.c:4611 break_stripe_batch_list+0x86/0x1fb
  • From: Marc Smith <msmith626@xxxxxxxxx>
• Re: [RFC] [PATCH V2 0/1] Introduce emergency raid0 stop for mounted arrays
  • From: "Guilherme G. Piccoli" <kernel@xxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Julien ROBIN <julien.robin28@xxxxxxx>
• Re: [RFC] [PATCH V2 0/1] Introduce emergency raid0 stop for mounted arrays
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Julien ROBIN <julien.robin28@xxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request()
  • From: Bart Van Assche <bvanassche@xxxxxxx>
• Re: [RFC] [PATCH V2 0/1] Introduce emergency raid0 stop for mounted arrays
  • From: "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxxxxx>
• [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios
  • From: "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxxxxx>
• [PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request()
  • From: "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Julien ROBIN <julien.robin28@xxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Julien ROBIN <julien.robin28@xxxxxxx>
• RAID5 mdadm --grow wrote nothing (Reshape Status : 0% complete) and cannot assemble anymore
  • From: Julien ROBIN <julien.robin28@xxxxxxx>
• Re: [PATCH] md: properly lock and unlock in rdev_attr_store()
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH] md: properly lock and unlock in rdev_attr_store()
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH] md: properly lock and unlock in rdev_attr_store()
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• Re: lost software raid information
  • From: "Wol's lists" <antlists@xxxxxxxxxxxxxxx>
• Re: best way to replace all disks
  • From: "Wol's lists" <antlists@xxxxxxxxxxxxxxx>
• Re: Unexpected difference between a 4-disk RAID5 and a 3-disk RAID5 reshaped into a 4-disk RAID5
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Unexpected difference between a 4-disk RAID5 and a 3-disk RAID5 reshaped into a 4-disk RAID5
  • From: pg@xxxxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Unexpected difference between a 4-disk RAID5 and a 3-disk RAID5 reshaped into a 4-disk RAID5
  • From: David Shaw <dshaw@xxxxxxxxxxxxxxx>
• Re: lost software raid information
  • From: Volker Lieder <v.lieder@xxxxxxxxxx>
• Re: lost software raid information
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: lost software raid information
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: lost software raid information
  • From: Volker Lieder <v.lieder@xxxxxxxxxx>
• Re: lost software raid information
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• lost software raid information
  • From: Volker Lieder <v.lieder@xxxxxxxxxx>
• Re: [PATCH] Assemble: print error message if mdadm fails assembling with --uuid option
  • From: Jinpu Wang <jinpu.wang@xxxxxxxxxxxxxxx>
• Re: best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• Re: best way to replace all disks
  • From: pg@xxxxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: best way to replace all disks
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: [GIT PULL] md-next 2019-04-19
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• Re: best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• Re: best way to replace all disks
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: best way to replace all disks
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: best way to replace all disks
  • From: Feng Zhang <prod.feng@xxxxxxxxx>
• Re: best way to replace all disks
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• Re: best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• Re: best way to replace all disks
  • From: Carsten Aulbert <carsten.aulbert@xxxxxxxxxx>
• Re: best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• best way to replace all disks
  • From: Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx>
• [GIT PULL] md-next 2019-04-19
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [RFC] [PATCH V2 0/1] Introduce emergency raid0 stop for mounted arrays
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [RFC] [PATCH V2 1/1] md/raid0: Introduce emergency stop for raid0 arrays
  • From: "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxxxxx>
• [RFC] [PATCH V2 0/1] Introduce emergency raid0 stop for mounted arrays
  • From: "Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH] Assemble: print error message if mdadm fails assembling with --uuid option
  • From: Gioh Kim <gi-oh.kim@xxxxxxxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• "echo frozen > /sys/block/md0/md/sync_action" locks up an array entirely
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: Replacing a member disk in RAID0
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Replacing a member disk in RAID0
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: Replacing a member disk in RAID0
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Replacing a member disk in RAID0
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: Replacing a member disk in RAID0
  • From: Guoqing Jiang <gqjiang@xxxxxxx>
• Replacing a member disk in RAID0
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: reduce number of devices in raid6
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: reduce number of devices in raid6
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• Re: reduce number of devices in raid6
  • From: "Wol's lists" <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• Re: reduce number of devices in raid6
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• Re: reduce number of devices in raid6
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Degraded RAID-6 array reassembling as a RAID-0 array
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: Degraded RAID-6 array reassembling as a RAID-0 array
  • From: Mark Wagner <carnildo@xxxxxxxxx>
• Re: [PATCH] md/raid0: don't use line[200] to store zone info
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: Degraded RAID-6 array reassembling as a RAID-0 array
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: [HELP] md/raid5: do we really avoid reading from known bad blocks ?
  • From: "jianchao.wang" <jianchao.w.wang@xxxxxxxxxx>
• Re: [GIT PULL] md fixes/changes for 5.2
  • From: Jens Axboe <axboe@xxxxxxxxx>
• [GIT PULL] md fixes/changes for 5.2
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [HELP] md/raid5: do we really avoid reading from known bad blocks ?
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] md/raid0: don't use line[200] to store zone info
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Degraded RAID-6 array reassembling as a RAID-0 array
  • From: Mark Wagner <carnildo@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Create: Block rounding size to max
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH 1/1] imsm: fix spare activation for old matrix arrays
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• Re: [PATCH 1/1] imsm: fix spare activation for old matrix arrays
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• [PATCH] md/raid0: don't use line[200] to store zone info
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• reduce number of devices in raid6
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• Re: Re[20]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: [HELP] md/raid5: do we really avoid reading from known bad blocks ?
  • From: "jianchao.wang" <jianchao.w.wang@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: John Stoffel <john@xxxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [HELP] md/raid5: do we really avoid reading from known bad blocks ?
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [HELP] md/raid5: do we really avoid reading from known bad blocks ?
  • From: "jianchao.wang" <jianchao.w.wang@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: One more newbee question:
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• One more newbee question:
  • From: "Renaud (Ron) OLGIATI" <renaud@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: OT: Processor recommendation
  • From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
• Re: OT: Processor recommendation
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• OT: Processor recommendation
  • From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
• Re: [PATCH 1/7] md: add a missing endianess conversion in check_sb_changes
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH 5/7] md: mark md_cluster_mod static
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: a bunch of MD raid fixes
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• seagate ST12000NM0007 disk issue
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• Re: Re[18]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Re[18]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re[18]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Re[16]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• [PATCH 7/7] md: add __acquires/__releases annotations to handle_active_stripes
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 6/7] md: add __acquires/__releases annotations to (un)lock_two_stripes
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 5/7] md: mark md_cluster_mod static
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 4/7] md: use correct type in super_1_sync
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 3/7] md: use correct type in super_1_load
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 2/7] md: use correct types in md_bitmap_print_sb
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 1/7] md: add a missing endianess conversion in check_sb_changes
  • From: Christoph Hellwig <hch@xxxxxx>
• a bunch of MD raid fixes
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re[16]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH v2] md: add mddev->pers to avoid potential NULL pointer dereference
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [PATCH v2] md: add mddev->pers to avoid potential NULL pointer dereference
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH v2] md: add mddev->pers to avoid potential NULL pointer dereference
  • From: Yufen Yu <yuyufen@xxxxxxxxxx>
• Re: [PATCH] md: add mddev->pers to avoid potential NULL pointer dereference
  • From: yuyufen <yuyufen@xxxxxxxxxx>
• Re: [PATCH] md: add mddev->pers to avoid potential NULL pointer dereference
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH] md: add mddev->pers to avoid potential NULL pointer dereference
  • From: Yufen Yu <yuyufen@xxxxxxxxxx>
• [PATCH] Create: Block rounding size to max
  • From: Mariusz Tkaczyk <mariusz.tkaczyk@xxxxxxxxx>
• Re: Help needed: RAID5 with two apparent simo drive failures
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Help needed: RAID5 with two apparent simo drive failures
  • From: "Jorge R. Frank" <jrfrank@xxxxxxxxxx>
• Re: Help needed: RAID5 with two apparent simo drive failures
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Help needed: RAID5 with two apparent simo drive failures
  • From: "Jorge R. Frank" <jrfrank@xxxxxxxxxx>
• Re: Question about Intel RST, NVMe SSDs and mdadm
  • From: Raphaël Halimi <raphael.halimi@xxxxxxxxx>
• Re: [PATCH 1/3] Don't jump to compute_result state from check_result state
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [PATCH 0/3] md fixes and improvements
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH 1/3] Don't jump to compute_result state from check_result state
  • From: Jens Axboe <axboe@xxxxxxxxx>
• [PATCH 2/3] Revert "MD: fix lock contention for flush bios"
  • From: Song Liu <songliubraving@xxxxxx>
• [PATCH 3/3] md: batch flush requests.
  • From: Song Liu <songliubraving@xxxxxx>
• [PATCH 1/3] Don't jump to compute_result state from check_result state
  • From: Song Liu <songliubraving@xxxxxx>
• [PATCH 0/3] md fixes and improvements
  • From: Song Liu <songliubraving@xxxxxx>
• Re: Question about Intel RST, NVMe SSDs and mdadm
  • From: Artur Paszkiewicz <artur.paszkiewicz@xxxxxxxxx>
• Re: [PATCH 0/2] md: change approach to parallel flush requests.
  • From: NeilBrown <neilb@xxxxxxxx>
• Question about Intel RST, NVMe SSDs and mdadm
  • From: Raphaël Halimi <raphael.halimi@xxxxxxxxx>
• Re: [PATCH 0/2] md: change approach to parallel flush requests.
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH 0/2] md: change approach to parallel flush requests.
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: [PATCH 0/2] md: change approach to parallel flush requests.
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: [PATCH 0/2] md: change approach to parallel flush requests.
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 1/1] md: return -ENODEV if rdev has no mddev assigned
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• Re: [PATCH 0/2] md: change approach to parallel flush requests.
  • From: Xiao Ni <xni@xxxxxxxxxx>
• [PATCH 1/2] Revert "MD: fix lock contention for flush bios"
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 0/2] md: change approach to parallel flush requests.
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 2/2] md: batch flush requests.
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH] Don't jump to compute_result state from check_result state
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: Re[14]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• [PATCH] Don't jump to compute_result state from check_result state
  • From: Nigel Croxon <ncroxon@xxxxxxxxxx>
• Re: [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: NeilBrown <neilb@xxxxxxxx>
• Re[14]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: Liwei Song <liwei.song@xxxxxxxxxxxxx>
• Re: [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: [PATCH] md:MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• [PATCH] udev: Add udev rules to create by-partuuid for md device
  • From: Liwei Song <liwei.song@xxxxxxxxxxxxx>
• Re: [PATCH] md:MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH] md:MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: 4tb NAS drive recommendation
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: [GIT PULL] md changes for 5.1
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: troubleshooting RAID-1 array break+resync on boot after upgrades to linux kernel v5.0.x ?
  • From: PGNet Dev <pgnet.dev@xxxxxxxxx>
• Re: troubleshooting RAID-1 array break+resync on boot after upgrades to linux kernel v5.0.x ?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• troubleshooting RAID-1 array break+resync on boot after upgrades to linux kernel v5.0.x ?
  • From: PGNet Dev <pgnet.dev@xxxxxxxxx>
• Re: 4tb NAS drive recommendation
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: 4tb NAS drive recommendation
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• [GIT PULL] md changes for 5.1
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [PATCH] md: Fix failed allocation of md_register_thread
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH 1/1] It's wrong to add len to sector_nr in raid10 reshape twice
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH v2] raid5: set write hint for PPL
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] raid5: set write hint for PPL
  • From: "Dabrowski, Mariusz" <mariusz.dabrowski@xxxxxxxxx>
• Re: 4tb NAS drive recommendation
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: 4tb NAS drive recommendation
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: 4tb NAS drive recommendation
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Kai Stian Olstad <raid+list@xxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Nix <nix@xxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Nix <nix@xxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: Re[13]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: "Wol's lists" <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Andy Smith <andy@xxxxxxxxxxxxxx>
• Re[13]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: smart short test crashes software raid array?
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Re[11]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Kent Dorfman <kent.dorfman766@xxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: Raid 5 painfully slow with linux 5.0.0
  • From: Michael Leun <linux-raid-20190308@xxxxxxxxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Kent Dorfman <kent.dorfman766@xxxxxxxxx>
• Re: smart short test crashes software raid array?
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• smart short test crashes software raid array?
  • From: Kent Dorfman <kent.dorfman766@xxxxxxxxx>
• Re[11]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: Re[9]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Re[9]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Re[8]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Re[8]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Raid 5 painfully slow with linux 5.0.0
  • From: linux-raid-20190308@xxxxxxxxxxxxxxx
• [PATCH 1/1] It's wrong to add len to sector_nr in raid10 reshape twice
  • From: Xiao Ni <xni@xxxxxxxxxx>
• [PATCH 1/1] imsm: fix spare activation for old matrix arrays
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• Re: [PATCH v2] raid5: set write hint for PPL
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re[9]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re[8]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: Re[6]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re[6]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: [PATCH] md: Fix failed allocation of md_register_thread
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH v2] raid5: set write hint for PPL
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: Re[4]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Re[4]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] raid5: set write hint for PPL
  • From: Song Liu <songliubraving@xxxxxx>
• Re[2]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: no_spam@xxxxxxxxxxxx
• Re: [PATCH v2] raid5: set write hint for PPL
  • From: "Dabrowski, Mariusz" <mariusz.dabrowski@xxxxxxxxx>
• Re: Re[2]: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Linux Raid + BTRFS: rookie mistake ... dd bs=1M
  • From: zittware@xxxxxxxxxxxxxxxxxxxxxxx
• Re: [PATCH] md: Fix failed allocation of md_register_thread
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH] md: Fix failed allocation of md_register_thread
  • From: Aditya Pakki <pakki001@xxxxxxx>
• Re: [PATCH] add missing units to --examine
  • From: Corey Hickey <bugfood-ml@xxxxxxxxxx>
• Re: Raid5 four drives missing
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: [PATCH] add missing units to --examine
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH 1/1] Assemble: Fix starting array with initial reshape checkpoint
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH V2] mdmon: wait for previous mdmon to exit during takeover
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] mdmon: don't attempt to manage new arrays when terminating
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: mdadm RAID10 configuration - performance
  • From: keld@xxxxxxxxxx
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Jon Hunter <jonathanh@xxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Jon Hunter <jonathanh@xxxxxxxxxx>
• Re: Raid5 reshape stuck - md0 process hang
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: Raid5 reshape stuck - md0 process hang
  • From: Brian <search@xxxxxxxxxxxxxx>
• Re: Raid5 reshape stuck - md0 process hang
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: Raid5 reshape stuck - md0 process hang
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: raid5 reshape is stuck when raid5 journal device miss
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: raid5 reshape is stuck when raid5 journal device miss
  • From: Xiao Ni <xni@xxxxxxxxxx>
• mdadm RAID10 configuration - performance
  • From: Guillermo F <guillefraz@xxxxxxxxx>
• Re: Raid5 reshape stuck - md0 process hang
  • From: "search@xxxxxxxxxxxxxx" <search@xxxxxxxxxxxxxx>
• Raid5 reshape stuck - md0 process hang
  • From: "search@xxxxxxxxxxxxxx" <search@xxxxxxxxxxxxxx>
• Raid5 stuck at reshape - md0 process hangs
  • From: "search@xxxxxxxxxxxxxx" <search@xxxxxxxxxxxxxx>
• Re: AW: [PATCH] lib/raid6: possibly use different gen and xor algorithms.,
  • From: Hristo Venev <hristo@xxxxxxxxxx>
• AW: [PATCH] lib/raid6: possibly use different gen and xor algorithms.,
  • From: Markus Stockhausen <stockhausen@xxxxxxxxxxx>
• [PATCH] lib/raid6: possibly use different gen and xor algorithms.,
  • From: Hristo Venev <hristo@xxxxxxxxxx>
• Re: Raid5 four drives missing
  • From: Romulo Albuquerque <romulo.albuquerque@xxxxxxxxx>
• [PATCH V2] mdmon: wait for previous mdmon to exit during takeover
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• [PATCH 1/1] Assemble: Fix starting array with initial reshape checkpoint
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• [PATCH] mdmon: don't attempt to manage new arrays when terminating
  • From: Artur Paszkiewicz <artur.paszkiewicz@xxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V15 14/18] block: enable multipage bvecs
  • From: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
• RE: RAID6 : Sequential Write Performance
  • From: Jean De Gyns <Jean.DeGyns@xxxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Bart Van Assche <bvanassche@xxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: Raid5 four drives missing
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• RE: RAID6 : Sequential Write Performance
  • From: Jean De Gyns <Jean.DeGyns@xxxxxxxxxx>
• Re: [PATCH 1/1] mdmon: wait for previous mdmon to exit during takeover
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• RE: RAID6 : Sequential Write Performance
  • From: Jean De Gyns <Jean.DeGyns@xxxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Bart Van Assche <bvanassche@xxxxxxx>
• Re: Raid5 four drives missing
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: [PATCH 1/1] mdmon: wait for previous mdmon to exit during takeover
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• Re: Raid5 four drives missing
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Raid5 four drives missing
  • From: Romulo Albuquerque <romulo.albuquerque@xxxxxxxxx>
• [PATCH v2] raid5: set write hint for PPL
  • From: Mariusz Dabrowski <mariusz.dabrowski@xxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V15 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• Re: [PATCH] add missing units to --examine
  • From: Corey Hickey <bugfood-ml@xxxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
  • From: Bart Van Assche <bvanassche@xxxxxxx>
• Re: [PATCH V15 00/18] block: support multi-page bvec
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
• Re: [PATCH V15 00/18] block: support multi-page bvec
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH V15 18/18] block: kill BLK_MQ_F_SG_MERGE
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 17/18] block: kill QUEUE_FLAG_NO_SG_MERGE
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 16/18] block: document usage of bio iterator helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 15/18] block: always define BIO_MAX_PAGES as 256
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 14/18] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 13/18] block: allow bio_for_each_segment_all() to iterate over multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 12/18] bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 11/18] block: loop: pass multi-page bvec to iov_iter
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 10/18] btrfs: use mp_bvec_last_segment to get bio's last page
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 09/18] fs/buffer.c: use bvec iterator to truncate the bio
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 08/18] block: introduce mp_bvec_last_segment()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 07/18] block: use bio_for_each_bvec() to map sg
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 06/18] block: use bio_for_each_bvec() to compute multi-page bvec count
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 05/18] block: introduce bio_for_each_bvec() and rq_for_each_bvec()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 04/18] block: introduce multi-page bvec helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 03/18] block: remove bvec_iter_rewind()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 02/18] block: don't use bio->bi_vcnt to figure out segment number
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 01/18] btrfs: look at bi_size for repair decisions
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V15 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: linux 4.19.19: md0_raid:1317 blocked for more than 120 seconds.
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH] mdadm/tests: add one test case for failfast of raid1
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [LSF/MM TOPIC] (again) THP for file systems
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: linux 4.19.19: md0_raid:1317 blocked for more than 120 seconds.
  • From: Wolfgang Walter <linux@xxxxxxx>
• Re: RAID6 : Sequential Write Performance
  • From: Wilson Jonathan <i400sjon@xxxxxxxxx>
• Re: [LSF/MM TOPIC] (again) THP for file systems
  • From: William Kucharski <william.kucharski@xxxxxxxxxx>
• Re: [PATCH] raid5: set write hint for PPL
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: linux 4.19.19: md0_raid:1317 blocked for more than 120 seconds.
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [LSF/MM TOPIC] (again) THP for file systems
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [LSF/MM TOPIC] (again) THP for file systems
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• [LSF/MM TOPIC] (again) THP for file systems
  • From: Song Liu <songliubraving@xxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
• Re: [PATCH] Fix reshape for decreasing data offset
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] add missing units to --examine
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] Detail.c: do not skip first character when calling xstrdup in Detail()
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Robert L Mathews <lists@xxxxxxxxxxxxx>
• RAID6 : Sequential Write Performance
  • From: Jean De Gyns <Jean.DeGyns@xxxxxxxxxx>
• Re: [PATCH 1/1] mdmon: wait for previous mdmon to exit during takeover
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• [PATCH 1/1] mdmon: wait for previous mdmon to exit during takeover
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• [PATCH] raid5: set write hint for PPL
  • From: Mariusz Dabrowski <mariusz.dabrowski@xxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: "Nik.Brt." <nik.brt@xxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Nix <nix@xxxxxxxxxxxxx>
• Re: [GIT PULL] md fix
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [GIT PULL] md fix
  • From: Song Liu <songliubraving@xxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Robin Hill <robin@xxxxxxxxxxxxxxx>
• Re: [GIT PULL] md fix
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Nix <nix@xxxxxxxxxxxxx>
• [GIT PULL] md fix
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Jinpu Wang <jinpu.wang@xxxxxxxxxxxxxxx>
• Re: linux 4.19.19: md0_raid:1317 blocked for more than 120 seconds.
  • From: Wolfgang Walter <linux@xxxxxxx>
• Re: [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Jinpu Wang <jinpu.wang@xxxxxxxxxxxxxxx>
• [PATCH] Detail.c: do not skip first character when calling xstrdup in Detail()
  • From: Coly Li <colyli@xxxxxxx>
• Re: [PATCH] Make --examine print sizes more consistently
  • From: Corey Hickey <bugfood-ml@xxxxxxxxxx>
• [PATCH] add missing units to --examine
  • From: bugfood-ml@xxxxxxxxxx
• Re: [PATCH] Fix reshape for decreasing data offset
  • From: Corey Hickey <bugfood-ml@xxxxxxxxxx>
• [PATCH] Fix reshape for decreasing data offset
  • From: bugfood-ml@xxxxxxxxxx
• Re: [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Fix spelling typpos.
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH 1/1] imsm: fix reshape for >2TB drives
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] imsm: finish recovery when drive with rebuild fails
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] Make --examine print sizes more consistently
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] Fix reshape for decreasing data offset
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Nate Dailey <nate.dailey@xxxxxxxxxxx>
• Re: [PATCH] Make --examine print sizes more consistently
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• linux 4.19.19: md0_raid:1317 blocked for more than 120 seconds.
  • From: Wolfgang Walter <linux@xxxxxxx>
• Re: [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Jinpu Wang <jinpu.wang@xxxxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Harald Dunkel <harri@xxxxxxxxx>
• Re: [PATCH] Make --examine print sizes more consistently
  • From: Corey Hickey <bugfood-ml@xxxxxxxxxx>
• Re: [PATCH] Fix reshape for decreasing data offset
  • From: Corey Hickey <bugfood-ml@xxxxxxxxxx>
• [PATCH V2] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Nate Dailey <nate.dailey@xxxxxxxxxxx>
• Re: [PATCH] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Nate Dailey <nate.dailey@xxxxxxxxxxx>
• Re: [PATCH] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH] imsm: finish recovery when drive with rebuild fails
  • From: Mariusz Tkaczyk <mariusz.tkaczyk@xxxxxxxxx>
• [PATCH] md/raid1: don't clear bitmap bits on interrupted recovery.
  • From: Nate Dailey <nate.dailey@xxxxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: [GIT PULL] md pull for 5.1
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [GIT PULL] md pull for 5.1
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [GIT PULL] md pull for 5.1
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [GIT PULL] md pull for 5.1
  • From: Jens Axboe <axboe@xxxxxxxxx>
• [GIT PULL] md pull for 5.1
  • From: Song Liu <songliubraving@xxxxxx>
• [PATCH 4.14 43/46] md/raid5: fix out of memory during raid cache recovery
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.20 79/80] md/raid5: fix out of memory during raid cache recovery
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.19 73/74] md/raid5: fix out of memory during raid cache recovery
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] raid1: simplify raid1_error function
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH] raid1: simplify raid1_error function
  • From: Yufen Yu <yuyufen@xxxxxxxxxx>
• Re: LSI RAID assembly
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: LSI RAID assembly
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: 李春 <pickup112@xxxxxxxxx>
• Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: LSI RAID assembly
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: LSI RAID assembly
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: LSI RAID assembly
  • From: dpr <dpr@xxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: 李春 <pickup112@xxxxxxxxx>
• LSI RAID assembly
  • From: Leslie Rhorer <lrhorer@xxxxxxxxxxxx>
• Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: 李春 <pickup112@xxxxxxxxx>
• Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: Disabling HDD write cache neccessary (hdparm -W0)?
  • From: "Nik.Brt." <nik.brt@xxxxxxxxxxxxx>
• Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: Jack Wang <xjtuwjp@xxxxxxxxx>
• mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
  • From: 李春 <pickup112@xxxxxxxxx>
• Re: [PATCH] md-linear: use struct_size() in kzalloc()
  • From: "Gustavo A. R. Silva" <gustavo@xxxxxxxxxxxxxx>
• Re: [PATCH] md-linear: use struct_size() in kzalloc()
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: Disabling HDD write cache neccessary (hdparm -W0)?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH] md-linear: use struct_size() in kzalloc()
  • From: "Gustavo A. R. Silva" <gustavo@xxxxxxxxxxxxxx>
• Re: Disabling HDD write cache neccessary (hdparm -W0)?
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: A (raid)-newbee question:
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [GIT PULL] md fixes for raid5-cache
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: Disabling HDD write cache neccessary (hdparm -W0)?
  • From: Werner Fischer <devlists@xxxxxxxx>
• Re: Disabling HDD write cache neccessary (hdparm -W0)?
  • From: piergiorgio.sartor@xxxxxxxx
• Disabling HDD write cache neccessary (hdparm -W0)?
  • From: Werner Fischer <devlists@xxxxxxxx>
• [GIT PULL] md fixes for raid5-cache
  • From: Song Liu <songliubraving@xxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• [PATCH AUTOSEL 4.19 205/258] md: fix raid10 hang issue caused by barrier
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH AUTOSEL 4.14 128/170] md: fix raid10 hang issue caused by barrier
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH 1/1] imsm: fix reshape for >2TB drives
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• [PATCH AUTOSEL 4.20 245/304] md: fix raid10 hang issue caused by barrier
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: A (raid)-newbee question:
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• A (raid)-newbee question:
  • From: "Renaud (Ron) OLGIATI" <renaud@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: "Nik.Brt." <nik.brt@xxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: "Nik.Brt." <nik.brt@xxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Harald Dunkel <harri@xxxxxxxxx>
• Re: raid1 out of sync, but which files are affected?
  • From: Eyal Lebedinsky <eyal@xxxxxxxxxxxxxx>
• raid1 out of sync, but which files are affected?
  • From: Harald Dunkel <harri@xxxxxxxxx>
• Re: raid456's devices_handle_discard_safely is unusably slow
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: Bugfix / feature requests for raid5cache (writeback)
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• raid456's devices_handle_discard_safely is unusably slow
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: Bugfix / feature requests for raid5cache (writeback)
  • From: "Nik.Brt." <nik.brt@xxxxxxxxxxxxx>
• Re: question about cache flushes and raid journal in writeback mode
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: Bugfix / feature requests for raid5cache (writeback)
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Bugfix / feature requests for raid5cache (writeback)
  • From: "Nik.Brt." <nik.brt@xxxxxxxxxxxxx>
• Re: question about cache flushes and raid journal in writeback mode
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: question about cache flushes and raid journal in writeback mode
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• question about cache flushes and raid journal in writeback mode
  • From: Michal Soltys <soltys@xxxxxxxx>
• Re: Trouble Shrinking RAID6 from 5 to 4 drives
  • From: Eric Pulvino <ericpulvino@xxxxxxxxx>
• Re: [PATCH V14 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: [PATCH V14 00/18] block: support multi-page bvec
  • From: Sagi Grimberg <sagi@xxxxxxxxxxx>
• Re: [PATCH V14 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V14 00/18] block: support multi-page bvec
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH V14 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 16/18] block: document usage of bio iterator helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V14 00/18] block: support multi-page bvec
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH V14 18/18] block: kill BLK_MQ_F_SG_MERGE
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 17/18] block: kill QUEUE_FLAG_NO_SG_MERGE
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 15/18] block: always define BIO_MAX_PAGES as 256
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 13/18] block: allow bio_for_each_segment_all() to iterate over multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 14/18] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 12/18] bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 10/18] btrfs: use mp_bvec_last_segment to get bio's last page
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 11/18] block: loop: pass multi-page bvec to iov_iter
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 09/18] fs/buffer.c: use bvec iterator to truncate the bio
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 07/18] block: use bio_for_each_mp_bvec() to map sg
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 08/18] block: introduce mp_bvec_last_segment()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 06/18] block: use bio_for_each_mp_bvec() to compute multi-page bvec count
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 05/18] block: introduce bio_for_each_mp_bvec() and rq_for_each_mp_bvec()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 04/18] block: introduce multi-page bvec helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 03/18] block: remove bvec_iter_rewind()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 02/18] block: don't use bio->bi_vcnt to figure out segment number
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 01/18] btrfs: look at bi_size for repair decisions
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V14 00/18] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Romulo Albuquerque <romulo.albuquerque@xxxxxxxxx>
• Re: Trouble Shrinking RAID6 from 5 to 4 drives
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Siniša Bandin <sinisa@xxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: Trouble Shrinking RAID6 from 5 to 4 drives
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Romulo Albuquerque <romulo.albuquerque@xxxxxxxxx>
• Trouble Shrinking RAID6 from 5 to 4 drives
  • From: Eric Pulvino <ericpulvino@xxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Carsten Aulbert <carsten.aulbert@xxxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Carsten Aulbert <carsten.aulbert@xxxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Two drives in RAID6 array experienced similar error at or near beginning of drive
  • From: Basil Mohamed Gohar <basilgohar@xxxxxxxxx>
• Re: Possible Setup Error On New /dev/mdX Device
  • From: Shaun Glass <shaunglass@xxxxxxxxx>
• Re: Possible Setup Error On New /dev/mdX Device
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Possible Setup Error On New /dev/mdX Device
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Possible Setup Error On New /dev/mdX Device
  • From: Shaun Glass <shaunglass@xxxxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Romulo Albuquerque <romulo.albuquerque@xxxxxxxxx>
• Re: raid5 revert-reshape issue
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• raid5 revert-reshape issue
  • From: Romulo Albuquerque <romulo.albuquerque@xxxxxxxxx>
• Writes-starving-reads with raid10 on cfq, deadline, mq-deadline and possibly bfq
  • From: Pol Van Aubel <linux-raid@xxxxxxx>
• [PATCH] Fix spelling typpos.
  • From: Dimitri John Ledkov <xnox@xxxxxxxxxx>
• Re: [PATCH V13 00/19] block: support multi-page bvec
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH] drivers/md.c: Make bio_alloc_mddev return bio_alloc_bioset
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH] drivers/md.c: Make bio_alloc_mddev return bio_alloc_bioset
  • From: Artur Paszkiewicz <artur.paszkiewicz@xxxxxxxxx>
• [PATCH V13 15/19] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 16/19] block: always define BIO_MAX_PAGES as 256
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 19/19] block: kill BLK_MQ_F_SG_MERGE
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 18/19] block: kill QUEUE_FLAG_NO_SG_MERGE
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 17/19] block: document usage of bio iterator helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 14/19] block: allow bio_for_each_segment_all() to iterate over multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 13/19] bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 12/19] block: loop: pass multi-page bvec to iov_iter
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 11/19] btrfs: use bvec_last_segment to get bio's last page
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 10/19] fs/buffer.c: use bvec iterator to truncate the bio
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 09/19] block: introduce bvec_last_segment()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 08/19] block: use bio_for_each_bvec() to map sg
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 07/19] block: use bio_for_each_bvec() to compute multi-page bvec count
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 06/19] block: introduce bio_for_each_bvec() and rq_for_each_bvec()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 05/19] block: introduce multi-page bvec helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 04/19] block: rename bvec helpers
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 03/19] block: remove bvec_iter_rewind()
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 02/19] block: don't use bio->bi_vcnt to figure out segment number
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 01/19] btrfs: look at bi_size for repair decisions
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• [PATCH V13 00/19] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH] drivers/md.c: Make bio_alloc_mddev return bio_alloc_bioset
  • From: Marcos Paulo de Souza <marcos.souza.org@xxxxxxxxx>
• [PATCH] Fix reshape for decreasing data offset
  • From: bugfood-ml@xxxxxxxxxx
• Re: [PATCH] md/raid10: Use struct_size() in kmalloc()
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] md-linear: use struct_size() in kzalloc()
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• Re: [PATCH] Make --examine print sizes more consistently
  • From: Song Liu <liu.song.a23@xxxxxxxxx>
• [PATCH] md-linear: use struct_size() in kzalloc()
  • From: "Gustavo A. R. Silva" <gustavo@xxxxxxxxxxxxxx>
• [PATCH] Make --examine print sizes more consistently
  • From: bugfood-ml@xxxxxxxxxx
• [PATCH] md/raid10: Use struct_size() in kmalloc()
  • From: "Gustavo A. R. Silva" <gustavo@xxxxxxxxxxxxxx>
• Re: Shaohua Li
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: Shaohua Li
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: Shaohua Li
  • From: Jinpu Wang <jinpuwang@xxxxxxxxx>
• Re: Shaohua Li
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: Software RAID memory issue?
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: Software RAID memory issue?
  • From: Richard Alloway <richard.alloway@xxxxxxxxxxxxx>
• Shaohua Li
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [RFC PATCH] raid6_pq: Add module options to prefer algorithm
  • From: Timofey Titovets <nefelim4ag@xxxxxxxxx>
• Re: raid5: BUG_ON(atomic_inc_return(&sh->count) != 1)
  • From: Anssi Hannula <anssi.hannula@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: My array won't assemble
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• [PATCH] drivers/md.c: Make bio_alloc_mddev return bio_alloc_bioset
  • From: Marcos Paulo de Souza <marcos.souza.org@xxxxxxxxx>
• Re: My array won't assemble
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: My array won't assemble
  • From: Alexis BRENON <brenon.alexis@xxxxxxxxx>
• Re: My array won't assemble
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: My array won't assemble
  • From: Alexis BRENON <brenon.alexis@xxxxxxxxx>
• Re: My array won't assemble
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: My array won't assemble
  • From: Alexis BRENON <brenon.alexis@xxxxxxxxx>
• Re: My array won't assemble
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• Re: My array won't assemble
  • From: Alexis BRENON <brenon.alexis@xxxxxxxxx>
• Re: My array won't assemble
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• BUG_ON() hit in drivers/md/raid5.c
  • From: Kai Heng Feng <kai.heng.feng@xxxxxxxxxxxxx>
• Re: My array won't assemble
  • From: Alexis BRENON <brenon.alexis@xxxxxxxxx>
• [PATCH] md: fix raid10 hang issue caused by barrier
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: My array won't assemble
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• My array won't assemble
  • From: Alexis BRENON <brenon.alexis@xxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Sinisa <sinisa@xxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Sinisa <sinisa@xxxxxxx>
• [PATCH 2/7] md: convert to kvmalloc
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• Re: [PATCH v2 0/2] Fix typo in RWH_WRITE_LIFE_NOT_SET constant name
  • From: Eugene Syromiatnikov <esyr@xxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Siniša Bandin <sinisa@xxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Sinisa <sinisa@xxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Sinisa <sinisa@xxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: keld@xxxxxxxxxx
• Re: Aw: Re: assemble broken raid5
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Sinisa <sinisa@xxxxxxx>
• Re: controller failed - help recreating array
  • From: Stephen Remde <stephen.remde@xxxxxxxxxxx>
• Aw: Re: assemble broken raid5
  • From: "Alex Sommer" <alex@xxxxxxxxxxxxxxx>
• Re: assemble broken raid5
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: controller failed - help recreating array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• assemble broken raid5
  • From: "Alex Sommer" <alex@xxxxxxxxxxxxxxx>
• controller failed - help recreating array
  • From: Stephen Remde <stephen.remde@xxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: XFS and RAID10 with o2 layout
  • From: Brian Foster <bfoster@xxxxxxxxxx>
• Re: [PATCH] policy.c: Fix for compiler error
  • From: "Tkaczyk, Mariusz" <mariusz.tkaczyk@xxxxxxxxx>
• Re: Software RAID memory issue?
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: Replacing MOBO seems to have disappeared my software RAID1...?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: [PATCH] policy.c: Fix for compiler error
  • From: Jes Sorensen <jsorensen@xxxxxx>
• Re: [PATCH] policy.c: prevent NULL pointer referencing
  • From: Jes Sorensen <jsorensen@xxxxxx>
• [PATCH] policy.c: Fix for compiler error
  • From: Mariusz Tkaczyk <mariusz.tkaczyk@xxxxxxxxx>
• Kernel bug on shli_md-for-next
  • From: "Tkaczyk, Mariusz" <mariusz.tkaczyk@xxxxxxxxx>
• Replacing MOBO seems to have disappeared my software RAID1...?
  • From: Signup <signup@xxxxxxxxxxxx>
• Re: Software RAID memory issue?
  • From: Richard Alloway <richard.alloway@xxxxxxxxxxxxx>
• Re: Software RAID memory issue?
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH] policy.c: prevent NULL pointer referencing
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Roger Heflin <rogerheflin@xxxxxxxxx>
• [PATCH] mdadm/tests: add one test case for failfast of raid1
  • From: Gioh Kim <gi-oh.kim@xxxxxxxxxxxxxxx>
• [PATCH] policy.c: prevent NULL pointer referencing
  • From: Gioh Kim <gi-oh.kim@xxxxxxxxxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: Niklas Hambüchen <mail@xxxxxx>
• [PATCH] raid10: refactor common wait code from regular read/write request
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: Software RAID memory issue?
  • From: Richard Alloway <richard.alloway@xxxxxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: [PATCHv2] Assemble: keep MD_DISK_FAILFAST and MD_DISK_WRITEMOSTLY flag
  • From: Jes Sorensen <jsorensen@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: Software RAID memory issue?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [PATCHv2] Assemble: keep MD_DISK_FAILFAST and MD_DISK_WRITEMOSTLY flag
  • From: Gi-Oh Kim <gi-oh.kim@xxxxxxxxxxxxxxx>
• Re: [PATCHv2] Assemble: keep MD_DISK_FAILFAST and MD_DISK_WRITEMOSTLY flag
  • From: Jes Sorensen <jsorensen@xxxxxx>
• Re: [PATCHv2] Assemble: keep MD_DISK_FAILFAST and MD_DISK_WRITEMOSTLY flag
  • From: Gi-Oh Kim <gi-oh.kim@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/2] Grow: report correct new chunk size.
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCHv2] Assemble: keep MD_DISK_FAILFAST and MD_DISK_WRITEMOSTLY flag
  • From: Gi-Oh Kim <gi-oh.kim@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] Grow: avoid overflow in compute_backup_blocks()
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [RFC] Assemble: mask FAILFAST and WRITEMOSTLY flags when finding the most recent device
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH] imsm: update metadata correctly while raid10 double degradation
  • From: Jes Sorensen <jes.sorensen@xxxxxxxxx>
• Re: [PATCH 0/2] mdadm fixes for Policy in mdadm.conf
  • From: Jes Sorensen <jsorensen@xxxxxx>
• Re: [PATCH 0/2] mdadm: add systemd units for periodic tasks.
  • From: Jes Sorensen <jsorensen@xxxxxx>
• Re: [PATCHv2] Assemble: keep MD_DISK_FAILFAST and MD_DISK_WRITEMOSTLY flag
  • From: Jes Sorensen <jsorensen@xxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 2/2] Grow: report correct new chunk size.
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 1/2] Grow: avoid overflow in compute_backup_blocks()
  • From: NeilBrown <neilb@xxxxxxxx>
• Software RAID memory issue?
  • From: Richard Alloway <richard.alloway@xxxxxxxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: raid1 becoming raid0 when device is removed before reboot
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 2/2] Monitor: add system timer to run --oneshot periodically
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 1/2] mdcheck: add systemd unit files to run mdcheck.
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH 0/2] mdadm: add systemd units for periodic tasks.
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: Revive a dead md raid5 array
  • From: Jogchum Reitsma <jogchum.reitsma@xxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: "Wol's lists" <antlists@xxxxxxxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Re: RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• RAID1 scrub ignoring read errors?
  • From: Niklas Hambüchen <mail@xxxxxx>
• Warnings related to mdadm_env.sh with systemd on non-SUSE distributions
  • From: Louis Sautier <sautier.louis@xxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: Ed Spiridonov <edo.rus@xxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: Ed Spiridonov <edo.rus@xxxxxxxxx>
• Restore RAID10 with 2 "non-fresh" disks after power outage?
  • From: Hannes <ghan@xxxxxx>
• Re: [PATCH V12 00/20] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: [PATCH V12 00/20] block: support multi-page bvec
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH V12 00/20] block: support multi-page bvec
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: Ed Spiridonov <edo.rus@xxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH V12 00/20] block: support multi-page bvec
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: Ed Spiridonov <edo.rus@xxxxxxxxx>
• Re: Revive a dead md raid5 array
  • From: Jogchum Reitsma <jogchum.reitsma@xxxxxxxxx>
• Re: [PATCH V12 16/20] block: enable multipage bvecs
  • From: Ming Lei <ming.lei@xxxxxxxxxx>
• Re: Issues with large chunk size (16Mb)
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH V12 16/20] block: enable multipage bvecs
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 02/20] btrfs: look at bi_size for repair decisions
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 17/20] block: always define BIO_MAX_PAGES as 256
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 18/20] block: document usage of bio iterator helpers
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 15/20] block: allow bio_for_each_segment_all() to iterate over multi-page bvec
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 14/20] bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages()
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 13/20] block: loop: pass multi-page bvec to iov_iter
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 09/20] block: use bio_for_each_bvec() to compute multi-page bvec count
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 01/20] btrfs: remove various bio_offset arguments
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 06/20] block: rename bvec helpers
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 05/20] block: remove bvec_iter_rewind()
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 04/20] block: don't use bio->bi_vcnt to figure out segment number
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 03/20] block: remove the "cluster" flag
  • From: Omar Sandoval <osandov@xxxxxxxxxxx>
• Re: [PATCH V12 10/20] block: use bio_for_each_bvec() to map sg
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH V12 09/20] block: use bio_for_each_bvec() to compute multi-page bvec count
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH V12 18/20] block: document usage of bio iterator helpers
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH V12 16/20] block: enable multipage bvecs
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH V12 08/20] block: introduce bio_for_each_bvec() and rq_for_each_bvec()
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH V12 07/20] block: introduce multi-page bvec helpers
  • From: Christoph Hellwig <hch@xxxxxx>