Linux RAID Storage Date Index

• Thread Index

• Re: WARNING: CPU: 4 PID: 10512 at drivers/md/raid5-cache.c:728 r5l_do_reclaim+0x415/0x430 [raid456]
  • From: yizhan <yizhan@xxxxxxxxxx>
• [PATCH 0315/1285] Replace numeric parameter like 0444 with macro
  • From: Baole Ni <baolex.ni@xxxxxxxxx>
• Re: Inactive arrays
  • From: Daniel Sanabria <sanabria.d@xxxxxxxxx>
• Re: WARNING: CPU: 4 PID: 10512 at drivers/md/raid5-cache.c:728 r5l_do_reclaim+0x415/0x430 [raid456]
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: Inactive arrays
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH 3/3] MD: hold mddev lock for md-cluster receive thread
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH] mdadm:add 'clustered' in typo prompt when specify wrong param for bitmap
  • From: Zhilong Liu <zlliu@xxxxxxxx>
• Inactive arrays
  • From: Daniel Sanabria <sanabria.d@xxxxxxxxx>
• Re: RAID5 Performance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 4/8] md-cluster: introduce dlm_lock_sync_interruptible to fix tasks hang
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH 1/8] md-cluster: call md_kick_rdev_from_array once ack failed
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH 6/8] md-cluster: make resync lock also could be interruptted
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH 6/8] md-cluster: make resync lock also could be interruptted
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH 4/8] md-cluster: introduce dlm_lock_sync_interruptible to fix tasks hang
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH 1/8] md-cluster: call md_kick_rdev_from_array once ack failed
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH 3/3] MD: hold mddev lock for md-cluster receive thread
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: xosview
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: xosview
  • From: Bill Hudacek <bill.hudacek@xxxxxxxxx>
• One question about raid10 resync
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: WARNING: CPU: 4 PID: 10512 at drivers/md/raid5-cache.c:728 r5l_do_reclaim+0x415/0x430 [raid456]
  • From: Yi Zhang <yizhan@xxxxxxxxxx>
• Re: WARNING: CPU: 4 PID: 10512 at drivers/md/raid5-cache.c:728 r5l_do_reclaim+0x415/0x430 [raid456]
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [PATCH 3/3] MD: hold mddev lock for md-cluster receive thread
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: To add, or not to add, a bio REQ_ROTATIONAL flag
  • From: Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] MD: hold mddev lock for .quiesce in md_do_sync
  • From: yizhan <yizhan@xxxxxxxxxx>
• [PATCH 2/3] MD: hold mddev lock to change bitmap location
  • From: shli@xxxxxxxxxx
• [PATCH 3/3] MD: hold mddev lock for md-cluster receive thread
  • From: shli@xxxxxxxxxx
• [PATCH 1/3] MD: hold mddev lock for .quiesce in md_do_sync
  • From: shli@xxxxxxxxxx
• Re: [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] raid10: increment write counter after bio is split
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: xosview
  • From: Glenn Enright <glenn.enright@xxxxxxxxx>
• xosview
  • From: Anthony Youngman <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
  • From: "Obitotskiy, Aleksey" <aleksey.obitotskiy@xxxxxxxxx>
• Re: To add, or not to add, a bio REQ_ROTATIONAL flag
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: To add, or not to add, a bio REQ_ROTATIONAL flag
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• To add, or not to add, a bio REQ_ROTATIONAL flag
  • From: Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx>
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: Andreas Dröscher <raid@xxxxxxxxxx>
• Re: RAID5 Performance
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: RAID5 Performance
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: RAID5 Performance
  • From: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
• [GIT PULL] MD update for 4.8
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: RAID5 Performance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: RAID5 Performance
  • From: Anthony Youngman <antlists@xxxxxxxxxxxxxxx>
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: Anthony Youngman <antlists@xxxxxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• [PATCH] raid10: increment write counter after bio is split
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: test file disappeared after -f, -r, --add-journal for write-journal device
  • From: yizhan <yizhan@xxxxxxxxxx>
• [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr
  • From: ZhengYuan Liu <liuzhengyuan@xxxxxxxxxx>
• [PATCH 8/8] md-cluster: remove EXPERIMENTAL info
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 6/8] md-cluster: make resync lock also could be interruptted
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 7/8] md-cluster: clean related infos of cluster
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 5/8] md: changes for MD_STILL_CLOSED flag
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 4/8] md-cluster: introduce dlm_lock_sync_interruptible to fix tasks hang
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 3/8] md-cluster: remove some unnecessary dlm_unlock_sync
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 2/8] md-cluster: use FORCEUNLOCK in lockres_free
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 1/8] md-cluster: call md_kick_rdev_from_array once ack failed
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: Kernel deadlock during mdadm reshape
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: test file disappeared after -f, -r, --add-journal for write-journal device
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: WARNING: CPU: 4 PID: 10512 at drivers/md/raid5-cache.c:728 r5l_do_reclaim+0x415/0x430 [raid456]
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: RAID5 Performance
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• SOLVED [was: Re: Lost RAID6 disks when moving to new PC]
  • From: Alex Owen <alex@xxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: Lost RAID6 disks when moving to new PC
  • From: Alex Owen <alex@xxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: RAID5 Performance
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: Anthony Youngman <antlists@xxxxxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: The subarray is loaded container by load_container
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Anthony Youngman <antlists@xxxxxxxxxxxxxxx>
• Re: SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: Anthony Youngman <antlists@xxxxxxxxxxxxxxx>
• test file disappeared after -f, -r, --add-journal for write-journal device
  • From: Yi Zhang <yizhan@xxxxxxxxxx>
• Re: Lost RAID6 disks when moving to new PC
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• WARNING: CPU: 4 PID: 10512 at drivers/md/raid5-cache.c:728 r5l_do_reclaim+0x415/0x430 [raid456]
  • From: Yi Zhang <yizhan@xxxxxxxxxx>
• Lost RAID6 disks when moving to new PC
  • From: Alex Owen <alex@xxxxxxxxxxxx>
• SOLVED [was Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?]
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: RAID5 Performance
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: RAID5 Performance
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• RAID5 Performance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Kernel deadlock during mdadm reshape
  • From: Michael Shaver <jmshaver@xxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: bobzer <bobzer@xxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• GPT Table broken on a Raid1 (necroposting)
  • From: Luis Panadero Guardeño <luis.panadero@xxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• migration of raid 5 to raid 6 and disk of 2TB to 4TB
  • From: bobzer <bobzer@xxxxxxxxx>
• Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: How does md gurantee not miss to free an active stripe_head when md stops?
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] mdcheck: Send progress messages to system log
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] Monitor: release /proc/mdstat fd when no arrays present
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH v3] Remove: container should wait for an array to release a drive
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• [PATCH v3] Remove: container should wait for an array to release a drive
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
  • From: Miklos Szeredi <mszeredi@xxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
  • From: Sheng Yang <sheng@xxxxxxxxxx>
• Re: [PATCH v2] Remove: container should wait for an array to release a drive
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• Re: How does md gurantee not miss to free an active stripe_head when md stops?
  • From: "Vaughan" <cxt9401@xxxxxxx>
• Re: Cannot start array on disk
  • From: Phil Turmel <philip@xxxxxxxxxx>
• [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr
  • From: Zhengyuan Liu <liuzhengyuang521@xxxxxxxxx>
• [PATCH v2] Remove: container should wait for an array to release a drive
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: [PATCH] raid10: improve random reads performance
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• RE: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
  • From: "Obitotskiy, Aleksey" <aleksey.obitotskiy@xxxxxxxxx>
• Re: Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
  • From: Sheng Yang <sheng@xxxxxxxxxx>
• Re: Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: a hard lockup in md raid5 sequential write (v4.7-rc7)
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Amit Biswas <abiswas@xxxxxxx>
• Re: [PATCH] raid10: improve random reads performance
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: Recovering RAID Volumes from 6 Disks
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH] md: add missing sysfs_notify on array_state update
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] Fix kernel module refcount handling
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] md: use seconds granularity for error logging
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Recovering RAID Volumes from 6 Disks
  • From: Amit Biswas <abiswas@xxxxxxx>
• Re: [PATCH] Remove: container should wait for an array to release a drive
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] Remove: container should wait for an array to release a drive
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: Cannot start array on disk
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [PATCH] Remove: container should wait for an array to release a drive
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: [PATCH] Remove: container should wait for an array to release a drive
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• superblock help
  • From: Bryan Hepworth <bryan.hepworth@xxxxxxxxxxxxxxx>
• Re: [PATCH] Remove: container should wait for an array to release a drive
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• [PATCH] Remove: container should wait for an array to release a drive
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: raid5/6: general protection fault in async_copy_data
  • From: Joey Liao <joeyliao@xxxxxxxx>
• Raid1 rcu stall while I/O stress test
  • From: Chien Lee <chienlee@xxxxxxxx>
• Re: Recover filenames from failed RAID0
  • From: keld@xxxxxxxxxx
• How does md gurantee not miss to free an active stripe_head when md stops?
  • From: "Vaughan" <cxt9401@xxxxxxx>
• a hard lockup in md raid5 sequential write (v4.7-rc7)
  • From: Coly Li <colyli@xxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage) with check/repair/sync
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Cannot start array on disk
  • From: Bhatia Amit <amitbhatia@xxxxxxxxxxxxxx>
• Re: Recover filenames from failed RAID0
  • From: Michel Dubois <michel.dubois.mtl@xxxxxxxxx>
• Re: Help with assembling a stopped array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Help with assembling a stopped array
  • From: Vegard Haugland <vegard@xxxxxxxxxxx>
• Re: dm: fix parameter to blk_delay_queue()
  • From: Tahsin Erdogan <tahsin@xxxxxxxxxx>
• Re: dm: fix parameter to blk_delay_queue()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm: fix parameter to blk_delay_queue()
  • From: Tahsin Erdogan <tahsin@xxxxxxxxxx>
• [PATCH] md: Prevent IO hold during accessing to failed raid5 array
  • From: Alexey Obitotskiy <aleksey.obitotskiy@xxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage) with check/repair/sync
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: Recover filenames from failed RAID0
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
• Re: Help with assembling a stopped array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Help with assembling a stopped array
  • From: Vegard Haugland <vegard@xxxxxxxxxxx>
• Re: [dm-devel] Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Fwd: kernel checksumming performance vs actual raid device performance
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: [dm-devel] Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Ondrej Kozina <okozina@xxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: Help with assembling a stopped array
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: kernel checksumming performance vs actual raid device performance
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Help with assembling a stopped array
  • From: Vegard Haugland <vegard@xxxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: NeilBrown <neilb@xxxxxxxx>
• kernel checksumming performance vs actual raid device performance
  • From: Matt Garman <matthew.garman@xxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Page Allocation Failures/OOM with dm-crypt on software RAID10 (Intel Rapid Storage)
  • From: Matthias Dahl <ml_linux-kernel@xxxxxxxxxxxxxxxx>
• Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [PATCH 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 1/1] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• [PATCH 0/1] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: dm: raid456 basic support
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• re: dm: raid456 basic support
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: The subarray is loaded container by load_container
  • From: Artur Paszkiewicz <artur.paszkiewicz@xxxxxxxxx>
• The subarray is loaded container by load_container
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: Request for assistance
  • From: o1bigtenor <o1bigtenor@xxxxxxxxx>
• Re: Request for assistance
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: Request for assistance
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Request for assistance
  • From: o1bigtenor <o1bigtenor@xxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: [PATCH RESENT] dm: Check kthread_run's return value
  • From: Minfei Huang <mnghuan@xxxxxxxxx>
• Re: [PATCH RESENT] dm: Check kthread_run's return value
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH RESENT] dm: Check kthread_run's return value
  • From: Minfei Huang <mnghuan@xxxxxxxxx>
• Re: [PATCH RESENT] dm: Check kthread_run's return value
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Request for assistance
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: Request for assistance
  • From: o1bigtenor <o1bigtenor@xxxxxxxxx>
• Re: Request for assistance
  • From: o1bigtenor <o1bigtenor@xxxxxxxxx>
• Re: Request for assistance
  • From: keld@xxxxxxxxxx
• Re: Request for assistance
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Request for assistance
  • From: o1bigtenor <o1bigtenor@xxxxxxxxx>
• Re: [PATCH v3 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: Jens Axboe <axboe@xxxxxx>
• [PATCH] Monitor: release /proc/mdstat fd when no arrays present
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• [PATCH RESENT] dm: Check kthread_run's return value
  • From: Minfei Huang <mnghuan@xxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• raid5/6: general protection fault in async_copy_data
  • From: Joey Liao <joeyliao@xxxxxxxx>
• Re: [PATCH v3 2/3] bcache: update document info
  • From: wangyijing <wangyijing@xxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH v3 2/3] bcache: update document info
  • From: Coly Li <i@xxxxxxx>
• [PATCH v3 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH v3 2/3] bcache: update document info
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH v3 3/3] bcache: Remove redundant block_size assignment
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• [PATCH v2 3/3] bcache: Remove redundant block_size assignment
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH v2 2/3] bcache: update document info
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH v2 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: Assembly of RAID6 with 48 disk fails
  • From: Soeren Grunewald <soeren.grunewald@xxxxxxx>
• Re: [RESEND PATCH 2/3] bcache: update document info
  • From: wangyijing <wangyijing@xxxxxxxxxx>
• Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: wangyijing <wangyijing@xxxxxxxxxx>
• Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: Coly Li <colyli@xxxxxxx>
• Re: [RESEND PATCH 2/3] bcache: update document info
  • From: Coly Li <colyli@xxxxxxx>
• Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: wangyijing <wangyijing@xxxxxxxxxx>
• Re: [RESEND PATCH 2/3] bcache: update document info
  • From: wangyijing <wangyijing@xxxxxxxxxx>
• Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH v2 05/12] aoeblk: Generate uevent after attribute available
  • From: Ed Cashin <ed.cashin@xxxxxxx>
• Re: [PATCH v2 04/12] axonrom: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• Re: [PATCH v2 04/12] axonrom: Generate uevent after attribute available
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Assembly of RAID6 with 48 disk fails
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Assembly of RAID6 with 48 disk fails
  • From: "Grunewald, Soeren" <soeren.grunewald@xxxxxxx>
• Re: [PATCH] bcache: Use setup_timer and mod_timer
  • From: Coly Li <colyli@xxxxxxx>
• [PATCH] bcache: Use setup_timer and mod_timer
  • From: Amitoj Kaur Chawla <amitoj1606@xxxxxxxxx>
• [PATCH] md: add missing sysfs_notify on array_state update
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v2 02/12] genhd: Honor gen_uevent and add disk_gen_uevents
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [PATCH v2 00/12] gendisk: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 02/12] genhd: Honor gen_uevent and add disk_gen_uevents
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 01/12] genhd: Add "gen_uevent" parameter to add_disk
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 03/12] virtio-blk: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 04/12] axonrom: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 07/12] pktcdvd: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 05/12] aoeblk: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 06/12] mtip32xx: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 08/12] zram: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 09/12] md: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 10/12] mmc: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 11/12] mtd: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• [PATCH v2 12/12] nvme: Generate uevent after attribute available
  • From: Fam Zheng <famz@xxxxxxxxxx>
• --detail --test exit status
  • From: Xavier Nicollet <nicollet@xxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Edward Kuns <eddie.kuns@xxxxxxxxx>
• Re: [PATCH 1/2] dm: update table type check for dax
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Zygo Blaxell <u0oo5pgu@xxxxxxxxxxxxxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: Coly Li <i@xxxxxxx>
• Re: [RESEND PATCH 2/3] bcache: update document info
  • From: Coly Li <i@xxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 1/2] dm: update table type check for dax
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] dm: update table type check for dax
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 2/2] dm snap: add fake origin_direct_access
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 1/2] dm: update table type check for dax
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 1/2] dm: update table type check for dax
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/2] fix dm-snap for dax
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• [PATCH 2/2] dm snap: add fake origin_direct_access
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 1/2] dm: update table type check for dax
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 0/2] Support DAX for device-mapper dm-linear devices
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID 10 / 2 Devices Layout question
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: RAID 10 / 2 Devices Layout question
  • From: keld@xxxxxxxxxx
• Re: RAID 10 / 2 Devices Layout question
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: URE, link resets, user hostile defaults
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: How assemble this array? All devices listed as spares and busy. Huh? Unclear what this means.
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• How assemble this array? All devices listed as spares and busy. Huh? Unclear what this means.
  • From: dave dowless <ddowless@xxxxxxxxx>
• URE, link resets, user hostile defaults
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
• Re: Reshapeing after 4 Days with 0.0% progress
  • From: iggy <info@xxxxxxxxx>
• Re: Reshapeing after 4 Days with 0.0% progress
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Reshapeing after 4 Days with 0.0% progress
  • From: iggy <info@xxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: RAID 10 / 2 Devices Layout question
  • From: Phil Turmel <philip@xxxxxxxxxx>
• RAID 10 / 2 Devices Layout question
  • From: Paul Roland <paulrolandw@xxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: Recommendations needed for RAID5 recovery
  • From: Another Sillyname <anothersname@xxxxxxxxxxxxxx>
• Recommendations needed for RAID5 recovery
  • From: Peter Gebhard <pgeb@xxxxxxxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm stripe: add DAX support
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH] dm stripe: add DAX support
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: dm stripe: add DAX support
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: dm stripe: add DAX support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm stripe: add DAX support
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• Re: block: fix blk_queue_split() resource exhaustion
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• [PATCH] raid10: improve random reads performance
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Ming Lei <ming.lei@xxxxxxxxxxxxx>
• Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  • From: Yigal Korman <yigal@xxxxxxxxxxxxx>
• Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  • From: Yigal Korman <yigal@xxxxxxxxxxxxx>
• Re: [PATCH] Documentation: fix wrong value in md.txt
  • From: Jonathan Corbet <corbet@xxxxxxx>
• [PATCH] Fix kernel module refcount handling
  • From: Alexey Obitotskiy <aleksey.obitotskiy@xxxxxxxxx>
• [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH v2 0/3] Support DAX for device-mapper dm-linear devices
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH v2 2/3] dm: add infrastructure for DAX support
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH v2 3/3] dm linear: add DAX support
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• [RFC] block: fix blk_queue_split() resource exhaustion
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• [PATCH] dm: Check kthread_run's return value
  • From: Minfei Huang <mnghuan@xxxxxxxxx>
• [RESEND PATCH 2/3] bcache: update document info
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [RESEND PATCH 3/3] bcache: Remove redundant block_size assignment
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Making spare active without sync?
  • From: Wakko Warner <wakko@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: unbalanced RAID5 / performance issues
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: unbalanced RAID5 / performance issues
  • From: Adam Goryachev <mailinglists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re:In foreign trade workers should Take the initiative to develop a good understanding of customers around the world!
  • From: "ts9" <ts9@xxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: unbalanced RAID5 / performance issues
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: unbalanced RAID5 / performance issues
  • From: "Jens-U. Mozdzen" <jmozdzen@xxxxxx>
• unbalanced RAID5 / performance issues
  • From: Adam Goryachev <adam@xxxxxxxxxxxxxxxxxxxxxx>
• [PATCH] md: use seconds granularity for error logging
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• re: dm: raid456 basic support
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [PATCH] Documentation: fix wrong value in md.txt
  • From: "Tiezhu Yang" <kernelpatch@xxxxxxx>
• Re: [PATCH 2/2] imsm: properly handle values of sync_completed
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH 1/2] imsm: add handling of sync_action is equal to 'idle'
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] monitor: Make sure that last_checkpoint is set to 0 after sync
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH 1/1] MDADM:Check mdinfo->reshape_active more times before calling Grow_continue
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] dm raid: don't use 'const' in function return
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: RAID1: deadlock between freeze_array and blk plug?
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• [PATCH 2/2] imsm: properly handle values of sync_completed
  • From: Alexey Obitotskiy <aleksey.obitotskiy@xxxxxxxxx>
• [PATCH 1/2] imsm: add handling of sync_action is equal to 'idle'
  • From: Alexey Obitotskiy <aleksey.obitotskiy@xxxxxxxxx>
• [PATCH 0/2] imsm: add extra handling of sync_action and sync_completed
  • From: Alexey Obitotskiy <aleksey.obitotskiy@xxxxxxxxx>
• [PATCH] monitor: Make sure that last_checkpoint is set to 0 after sync
  • From: Pawel Baldysiak <pawel.baldysiak@xxxxxxxxx>
• [PATCH] dm raid: don't use 'const' in function return
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: RAID1: deadlock between freeze_array and blk plug?
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• [PATCH] mdadm: protecting sys_name overflow
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• Re: [PATCH] mdadm: protecting sys_name overflow
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• [PATCH 1/1] MDADM:Check mdinfo->reshape_active more times before calling Grow_continue
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: BLKZEROOUT not zeroing md dev on VMDK
  • From: Sitsofe Wheeler <sitsofe@xxxxxxxxx>
• Re: [PATCH 1/1] MDADM:Check mdinfo->reshape_active more times before calling Grow_continue
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] mdadm: protecting sys_name overflow
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: BLKZEROOUT not zeroing md dev on VMDK
  • From: Arvind Kumar <arvindkumar@xxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Benjamin ESTRABAUD <ben.estrabaud@xxxxxxxxxx>
• [PATCH] mdadm: protecting sys_name overflow
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Nicolas Noble <nicolas@xxxxxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Benjamin ESTRABAUD <ben.estrabaud@xxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Nicolas Noble <nicolas@xxxxxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Nicolas Noble <nicolas@xxxxxxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• [PATCH 1/1] MDADM:Check mdinfo->reshape_active more times before calling Grow_continue
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Nicolas Noble <nicolas@xxxxxxxxxxxxxx>
• Re: Failure propagation of concatenated raids ?
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Failure propagation of concatenated raids ?
  • From: Nicolas Noble <nicolas@xxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH 1/1] MDADM:Check mdinfo->reshape_active more times before calling Grow_continue
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH 1/4] raid1: Add a filed array_frozen to indicate whether raid in freeze state.
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: "Kani, Toshimitsu" <toshi.kani@xxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 0/6] Support DAX for device-mapper dm-linear devices
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 2/6] block: Check GENHD_FL_DAX for DAX capability
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 1/6] genhd: Add GENHD_FL_DAX to gendisk flags
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 5/6] dm, dm-linear: Add dax_supported to dm_target
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 3/6] dm: Add dm_blk_direct_access() for mapped device
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 4/6] dm-linear: Add linear_direct_access()
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• [PATCH 6/6] dm: Enable DAX support for mapper device
  • From: Toshi Kani <toshi.kani@xxxxxxx>
• Re: [PATCH] raid1/raid10: slow down resync if there is non-resync activity pending
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH 1/1] MD:Update superblock when err == 0 in size_store
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [GIT PULL REQUEST] md fixes for 4.3
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• [PATCH] raid1/raid10: slow down resync if there is non-resync activity pending
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: [GIT PULL REQUEST] md fixes for 4.3
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• RAID1: deadlock between freeze_array and blk plug?
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• Re: [GIT PULL REQUEST] md fixes for 4.3
  • From: Alexander Lyakas <alex.bolshoy@xxxxxxxxx>
• [PATCH 1/1] MD:Update superblock when err == 0 in size_store
  • From: Xiao Ni <xni@xxxxxxxxxx>
• [PATCH 1/1] MDADM:Check mdinfo->reshape_active more times before calling Grow_continue
  • From: Xiao Ni <xni@xxxxxxxxxx>
• Re: [PATCH] bcache: Remove deprecated create_workqueue
  • From: Jens Axboe <axboe@xxxxxx>
• Re: [PATCH] bcache: Remove deprecated create_workqueue
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: Low RAID10 performance during resync
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [md PATCH 05/18] md/raid10: add rcu protection to rdev access in raid10_sync_request.
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• Re: Low RAID10 performance during resync
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• Re: Low RAID10 performance during resync
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [md PATCH 09/18] md/raid10: stop print_conf from being too verbose.
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [md PATCH 05/18] md/raid10: add rcu protection to rdev access in raid10_sync_request.
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [md PATCH 01/18] md: disconnect device from personality before trying to remove it.
  • From: NeilBrown <neilb@xxxxxxxx>
• [PATCH] mdadm --detail --scan causes SIGABRT
  • From: Nikhil Kshirsagar <nkshirsa@xxxxxxxxxx>
• Re: Low RAID10 performance during resync
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH] md: use a mutex to protect a global list
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Low RAID10 performance during resync
  • From: Tomasz Majchrzak <tomasz.majchrzak@xxxxxxxxx>
• RE: restarting raid arrays with uuid
  • From: Bryan Hepworth <bryan.hepworth@xxxxxxxxxxxxxxx>
• Multithread raid5: Is check-for-completions also multithreaded (using async_xor) ?
  • From: "Aggarwal, Vikas" <Vikas.Aggarwal@xxxxxxxxxx>
• Re: mdadm 3.4-1, error msg. on boot - no /usr/lib/systemd/scripts/mdadm_env.sh
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• [PATCH] md: use a mutex to protect a global list
  • From: Cong Wang <xiyou.wangcong@xxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• [PATCH] bcache: Remove deprecated create_workqueue
  • From: Bhaktipriya Shridhar <bhaktipriya96@xxxxxxxxx>
• Re: mdadm 3.4-1, error msg. on boot - no /usr/lib/systemd/scripts/mdadm_env.sh
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Marc MERLIN <marc@xxxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Phil Turmel <philip@xxxxxxxxxx>
• [RFC v4 0/4] Introduce the bulk mode method when sending request to crypto layer
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v4 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v4 3/4] md: dm-crypt: Introduce the bulk mode method when sending request
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v4 1/4] block: Introduce blk_bio_map_sg() to map one bio
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: Doubts on async_tx xor offload for raid5/6
  • From: Vinod Koul <vinod.koul@xxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Roman Mamedov <rm@xxxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Marc MERLIN <marc@xxxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Marc MERLIN <marc@xxxxxxxxxxx>
• Re: xfs_repair fails after trying to format log cycle?
  • From: Andrew Ryder <tireman@xxxxxxx>
• Re: xfs_repair fails after trying to format log cycle?
  • From: Andrew Ryder <tireman@xxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Sarah Newman <srn@xxxxxxxxx>
• restarting raid arrays with uuid
  • From: Bryan Hepworth <bryan.hepworth@xxxxxxxxxxxxxxx>
• Re: Raid check didn't fix Current_Pending_Sector, but badblocks -nsv did
  • From: Marc MERLIN <marc@xxxxxxxxxxx>
• Re: [PATCH 28/45] target: use bio op accessors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 28/45] target: use bio op accessors
  • From: Mike Christie <mchristi@xxxxxxxxxx>
• Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 41/45] block, drivers, fs: shrink bi_rw from long to int
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 40/45] block: move bio io prio to a new field
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 37/45] drivers: use req op accessor
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 28/45] target: use bio op accessors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 25/45] bcache: use bio op accessors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 24/45] dm: use bio op accessors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 09/45] block discard: use bio set op accessor
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 08/45] block, fs, mm, drivers: use bio set/get op accessors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 07/45] bcache: use op_is_write instead of checking for REQ_WRITE
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 06/45] dm: use op_is_write instead of checking for REQ_WRITE
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 05/45] block, drivers, cgroup: use op_is_write helper instead of checking for REQ_WRITE
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 02/45] block: add REQ_OP definitions and helpers
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 01/45] block/fs/drivers: remove rw argument from submit_bio
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC v2 1/3] block: Introduce blk_bio_map_sg() to map one bio
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v2 1/3] block: Introduce blk_bio_map_sg() to map one bio
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• mdadm 3.4-1, error msg. on boot - no /usr/lib/systemd/scripts/mdadm_env.sh
  • From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 01/45] block/fs/drivers: remove rw argument from submit_bio
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 01/45] block/fs/drivers: remove rw argument from submit_bio
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 01/45] block/fs/drivers: remove rw argument from submit_bio
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [PATCH 08/45] block, fs, mm, drivers: use bio set/get op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 09/45] block discard: use bio set op accessor
  • From: mchristi@xxxxxxxxxx
• [PATCH 10/45] direct-io: use bio set/get op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 03/45] fs: have submit_bh users pass in op and flags separately
  • From: mchristi@xxxxxxxxxx
• [PATCH 11/45] btrfs: have submit_one_bio users use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 12/45] btrfs: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 13/45] btrfs: update __btrfs_map_block for REQ_OP transition
  • From: mchristi@xxxxxxxxxx
• [PATCH 06/45] dm: use op_is_write instead of checking for REQ_WRITE
  • From: mchristi@xxxxxxxxxx
• [PATCH 15/45] f2fs: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 16/45] gfs2: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 18/45] hfsplus: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 07/45] bcache: use op_is_write instead of checking for REQ_WRITE
  • From: mchristi@xxxxxxxxxx
• [PATCH 19/45] mpage: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 14/45] btrfs: use bio fields for op and flags
  • From: mchristi@xxxxxxxxxx
• [PATCH 17/45] xfs: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 22/45] pm: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 20/45] nilfs: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 21/45] ocfs2: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 24/45] dm: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 25/45] bcache: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 26/45] drbd: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 27/45] md: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 29/45] xen: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 30/45] block: copy bio op to request op
  • From: mchristi@xxxxxxxxxx
• [PATCH 31/45] block: prepare request creation/destruction code to use REQ_OPs
  • From: mchristi@xxxxxxxxxx
• [PATCH 32/45] block: prepare mq request creation to use REQ_OPs
  • From: mchristi@xxxxxxxxxx
• [PATCH 33/45] block: prepare elevator to use REQ_OPs.
  • From: mchristi@xxxxxxxxxx
• [PATCH 34/45] blkg_rwstat: separate op from flags
  • From: mchristi@xxxxxxxxxx
• [PATCH 35/45] block: convert merge/insert code to check for REQ_OPs.
  • From: mchristi@xxxxxxxxxx
• [PATCH 36/45] block: convert is_sync helpers to use REQ_OPs.
  • From: mchristi@xxxxxxxxxx
• [PATCH 37/45] drivers: use req op accessor
  • From: mchristi@xxxxxxxxxx
• [PATCH 38/45] blktrace: use op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 39/45] ide cd: do not set REQ_WRITE on requests.
  • From: mchristi@xxxxxxxxxx
• [PATCH 40/45] block: move bio io prio to a new field
  • From: mchristi@xxxxxxxxxx
• [PATCH 41/45] block, drivers, fs: shrink bi_rw from long to int
  • From: mchristi@xxxxxxxxxx
• [PATCH 44/45] block: do not use REQ_FLUSH for tracking flush support
  • From: mchristi@xxxxxxxxxx
• [PATCH 45/45] block, drivers, fs: rename REQ_FLUSH to REQ_PREFLUSH
  • From: mchristi@xxxxxxxxxx
• [PATCH 43/45] block, drivers: add REQ_OP_FLUSH operation
  • From: mchristi@xxxxxxxxxx
• [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
  • From: mchristi@xxxxxxxxxx
• [PATCH 28/45] target: use bio op accessors
  • From: mchristi@xxxxxxxxxx
• [PATCH 23/45] dm: pass dm stats data dir instead of bi_rw
  • From: mchristi@xxxxxxxxxx
• [PATCH 01/45] block/fs/drivers: remove rw argument from submit_bio
  • From: mchristi@xxxxxxxxxx
• [PATCH 02/45] block: add REQ_OP definitions and helpers
  • From: mchristi@xxxxxxxxxx
• [PATCH 04/45] fs: have ll_rw_block users pass in op and flags separately
  • From: mchristi@xxxxxxxxxx
• [PATCH 05/45] block, drivers, cgroup: use op_is_write helper instead of checking for REQ_WRITE
  • From: mchristi@xxxxxxxxxx
• [PATCH 00/45] v8: separate operations from flags in the bio/request structs
  • From: mchristi@xxxxxxxxxx
• [no subject]
  • From: Vikas Aggarwal <vik.reck@xxxxxxxxx>
• Re: raid 5 crashed
  • From: bobzer <bobzer@xxxxxxxxx>
• Re: [PATCH 1/2] md-cluster: fix deadlock issue when add disk to an recoverying array
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [md PATCH 09/18] md/raid10: stop print_conf from being too verbose.
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [md PATCH 05/18] md/raid10: add rcu protection to rdev access in raid10_sync_request.
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [md PATCH 01/18] md: disconnect device from personality before trying to remove it.
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [md PATCH 00/18] Assorted minor fixes, particularly RCU protection.
  • From: Shaohua Li <shli@xxxxxxxxxx>
• Re: [PATCH 0/2] Fixes for lots of arrays
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: raid 5 crashed
  • From: Sarah Newman <srn@xxxxxxxxx>
• Re: raid 5 crashed
  • From: bobzer <bobzer@xxxxxxxxx>
• Re: [RFC v2 1/3] block: Introduce blk_bio_map_sg() to map one bio
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [RFC v2 1/3] block: Introduce blk_bio_map_sg() to map one bio
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [PATCH 2/2] md: simplify the code with md_kick_rdev_from_array
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• [PATCH 1/2] md-cluster: fix deadlock issue when add disk to an recoverying array
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: raid 5 crashed
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: [md PATCH 09/18] md/raid10: stop print_conf from being too verbose.
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [md PATCH 09/18] md/raid10: stop print_conf from being too verbose.
  • From: "John Stoffel" <john@xxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: Why does raid0 set max_hw_sectors as chunk size but the other raid types doesn't?
  • From: Joey Liao <joeyliao@xxxxxxxx>
• Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Doubts on async_tx xor offload for raid5/6
  • From: Vikas Aggarwal <vik.reck@xxxxxxxxx>
• [md PATCH 18/18] md: reduce the number of synchronize_rcu() calls when multiple devices fail.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 17/18] md: be extra careful not to take a reference to a Faulty device.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 16/18] md/multipath: add rcu protection to rdev access in multipath_status.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 15/18] md/raid5: add rcu protection to rdev accesses in raid5_status.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 14/18] md/raid5: add rcu protection to rdev accesses in want_replace
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 13/18] md/raid5: add rcu protection to rdev accesses in handle_failed_sync.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 12/18] md/raid1: add rcu protection to rdev in fix_read_error
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 10/18] md/raid1: small cleanup in raid1_end_read/write_request
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 11/18] md/raid1: small code cleanup in end_sync_write
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 09/18] md/raid10: stop print_conf from being too verbose.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 08/18] md/raid10: simplify print_conf a little.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 07/18] md/raid10: minor code improvement in fix_read_error()
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 06/18] md/raid10: add rcu protection to rdev access during reshape.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 05/18] md/raid10: add rcu protection to rdev access in raid10_sync_request.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 04/18] md/raid10: add rcu protection in raid10_status.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 03/18] md/raid10: fix refounct imbalance when resyncing an array with a replacement device.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 02/18] md/raid1, raid10: don't recheck "Faulty" flag in read-balance.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 01/18] md: disconnect device from personality before trying to remove it.
  • From: NeilBrown <neilb@xxxxxxxx>
• [md PATCH 00/18] Assorted minor fixes, particularly RCU protection.
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: raid 5 crashed
  • From: Mikael Abrahamsson <swmike@xxxxxxxxx>
• Re: Why does raid0 set max_hw_sectors as chunk size but the other raid types doesn't?
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• Re: [PATCH 0/2] Fixes for lots of arrays
  • From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx>
• Re: raid 5 crashed
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: [RFC 4/5] r5cache: write part of r5cache
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• RE: [PATCH] dm-log-writes: fix bug with too large bios
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: raid 5 crashed
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: raid 5 crashed
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: dm-log-writes: fix bug with too large bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC 4/5] r5cache: write part of r5cache
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [RFC 5/5] r5cache: naive reclaim approach
  • From: Song Liu <songliubraving@xxxxxx>
• Re: [RFC 3/5] r5cache: look up stripe cache for chunk_aligned_read
  • From: Song Liu <songliubraving@xxxxxx>
• Re: RAID6 recovery with 6/9 drives out-of-sync
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [RFC 1/5] add bio_split_mddev
  • From: Song Liu <songliubraving@xxxxxx>
• Re: RAID6 recovery with 6/9 drives out-of-sync
  • From: "Peckins, Steven E" <speckins@xxxxxxxxxxxx>
• Re: [RFC 4/5] r5cache: write part of r5cache
  • From: Song Liu <songliubraving@xxxxxx>
• Re: RAID6 recovery with 6/9 drives out-of-sync
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: RAID6 recovery with 6/9 drives out-of-sync
  • From: "Peckins, Steven E" <speckins@xxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Edward Kuns <eddie.kuns@xxxxxxxxx>
• Re: BLKZEROOUT not zeroing md dev on VMDK
  • From: Sitsofe Wheeler <sitsofe@xxxxxxxxx>
• [RFC v3 0/4] Introduce the bulk mode method when sending request to crypto layer
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v3 1/4] block: Introduce blk_bio_map_sg() to map one bio
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v3 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v3 3/4] md: dm-crypt: Introduce the bulk mode method when sending request
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v3 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• RE: [PATCH] dm-log-writes: fix bug with too large bios
  • From: "James Johnston" <johnstonj.public@xxxxxxxxxxxx>
• RE: [PATCH] dm-crypt: Fix error with too large bios (was: bcache gets stuck flushing writeback cache when used in combination with LUKS/dm-crypt and non-default bucket size)
  • From: "James Johnston" <johnstonj.public@xxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Edward Kuns <eddie.kuns@xxxxxxxxx>
• Re: [RFC 5/5] r5cache: naive reclaim approach
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• Re: [RFC 4/5] r5cache: write part of r5cache
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• Re: [RFC 3/5] r5cache: look up stripe cache for chunk_aligned_read
  • From: NeilBrown <nfbrown@xxxxxxxxxx>
• Re: raid 5 crashed
  • From: Brad Campbell <lists2009@xxxxxxxxxxxxxxx>
• Re: RAID6 recovery with 6/9 drives out-of-sync
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: raid 5 crashed
  • From: Wols Lists <antlists@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/2] Fixes for lots of arrays
  • From: Mike Lovell <mlovell@xxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Phil Turmel <philip@xxxxxxxxxx>
• Re: [RFC 1/5] add bio_split_mddev
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• Re: [RFC 4/5] r5cache: write part of r5cache
  • From: Guoqing Jiang <gqjiang@xxxxxxxx>
• RAID6 recovery with 6/9 drives out-of-sync
  • From: "Peckins, Steven E" <speckins@xxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: bobzer <bobzer@xxxxxxxxx>
• [PATCH 1/1] md/bitmap.c:bitmap_status(): Fix filename escaping
  • From: Nominal Animal <kernel@xxxxxxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: Anthonys Lists <antlists@xxxxxxxxxxxxxxx>
• Re: raid 5 crashed
  • From: bobzer <bobzer@xxxxxxxxx>
• Why does raid0 set max_hw_sectors as chunk size but the other raid types doesn't?
  • From: Joey Liao <joeyliao@xxxxxxxx>
• Re: raid 5 crashed
  • From: bobzer <bobzer@xxxxxxxxx>
• Re: [PATCH] dm-log-writes: fix bug with too large bios
  • From: Josef Bacik <jbacik@xxxxxx>
• [PATCH] dm-log-writes: fix bug with too large bios
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm-crypt: Fix error with too large bios (was: bcache gets stuck flushing writeback cache when used in combination with LUKS/dm-crypt and non-default bucket size)
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [RFC v2 1/3] block: Introduce blk_bio_map_sg() to map one bio
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v2 3/3] md: dm-crypt: Introduce the bulk mode method when sending request
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC v2 0/3] Introduce the bulk mode method when sending request to crypto layer
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: BLKZEROOUT not zeroing md dev on VMDK
  • From: Tom Yan <tom.ty89@xxxxxxxxx>
• Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Milan Broz <gmazyland@xxxxxxxxx>
• Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
  • From: Milan Broz <gmazyland@xxxxxxxxx>
• Re: [RFC 3/3] md: dm-crypt: Introduce the bulk mode method when sending request
  • From: Baolin Wang <baolin.wang@xxxxxxxxxx>
• [RFC 5/5] r5cache: naive reclaim approach
  • From: Song Liu <songliubraving@xxxxxx>