Linux Device-Mapper Development
[Prev Page][Next Page]
- UUID homogenization
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Differentiating between dm devices
- From: Phillip Susi <psusi@xxxxxxxxxx>
- dm-ioband max-bw and min-bw
- From: Степан Фёдоров <stepan.fedorov@xxxxxxxx>
- difference in running multipathd in console versus cron
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- multipath-tools and IBM 2810 XIV
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- mirror target memory consumption
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: FW: the mirror log is NOT kept on disk
- From: Milan Broz <mbroz@xxxxxxxxxx>
- FW: the mirror log is NOT kept on disk
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- the mirror log is NOT kept on disk
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- multipath-tools libmultipath/dict.c libmultipa ...
- From: bmarzins@xxxxxxxxxxxxxx
- orphan status and mixed pvs
- From: "Janec, Jozef" <jozef.janec@xxxxxx>
- Re: [RFC][PATCH] dm: improve read performance
- From: Nikanth Karthikesan <knikanth@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Evgeniy Polyakov <zbr@xxxxxxxxxxx>
- Re: [PATCH v2] dm-throttle: new device mapper target to throttle reads and writes
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- Re: [RFC][PATCH] dm: improve read performance
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- multipath performance problem
- From: Leonid Podolny <leonid.podolny@xxxxxxxxxxx>
- Re: [PATCH v2] dm-throttle: new device mapper target to throttle reads and writes
- From: Juerg Haefliger <juergh@xxxxxxxxx>
- Re: [RFC][PATCH] dm: improve read performance
- From: Nikanth Karthikesan <knikanth@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- [PATCH v4] dm stripe: implement merge method
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 04/13] dm: use list_move() instead of list_del()/list_add() combination
- From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
- Re: [PATCH v3] dm stripe: implement merge method
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- shared snapshot LVM patch compile error
- From: devicemapper niko <devicemapper.niko@xxxxxxxxx>
- Re: [PATCH v3] dm stripe: implement merge method
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
- Re: [PATCH v3] dm stripe: implement merge method
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH] block: Require subsystems to explicitly allocate bio_set integrity mempool
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: [PATCH] block: Require subsystems to explicitly allocate bio_set integrity mempool (was: Re: mirrored device with thousand of mappingtableentries)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [patch] Add MD36xxf into RDAC device list
- From: <Yanqing_Liu@xxxxxxxx>
- [MULTIPATH] Help to understand some points
- From: Guillaume Camera <camera.g@xxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Martin K. Petersen" <mkp@xxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [PATCH v3] dm stripe: implement merge method
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Dave Chinner <david@xxxxxxxxxxxxx>
- Re: [PATCH 05/10] block: remove per-queue plugging
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Dave Chinner <david@xxxxxxxxxxxxx>
- [PATCH] Wipe buffer even if vamlloc fails
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Wendy Cheng <s.wendy.cheng@xxxxxxxxx>
- Re: How does dm-thinp handle the our of space error?
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- dmsetup do not know sda*
- From: yue <ooolinux@xxxxxxx>
- How does dm-thinp handle the our of space error?
- From: Xie Gang <xiegang112@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Dave Chinner <david@xxxxxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Andreas Dilger <adilger@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
- [PATCH] Fix using of possible uninitialised params struct (secure flag)
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Patrick McHardy <kaber@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Josef Bacik <josef@xxxxxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Evgeniy Polyakov <zbr@xxxxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: generic wrappers for multi-device FS operations
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- generic wrappers for multi-device FS operations
- From: Ric Wheeler <ricwheeler@xxxxxxxxx>
- Re: [PATCH v3] dm stripe: implement merge method
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm: Integrity errors should not cause failover
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm: Integrity errors should not cause failover
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: dm: Integrity errors should not cause failover
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: dm: Integrity errors should not cause failover
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Patrick McHardy <kaber@xxxxxxxxx>
- Re: [PATCH v3] dm stripe: implement merge method
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
- Re: multipath-tools multipath.conf.synthetic
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- [PATCH] dm: Integrity errors should not cause failover
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Martin K. Petersen" <mkp@xxxxxxx>
- [PATCH v3] dm stripe: implement merge method
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: [PATCH] multipath: Retry host transient errors for rdac checker
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- multipath-tools multipath.conf.synthetic
- From: bmarzins@xxxxxxxxxxxxxx
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- multipath-tools/libmultipath discovery.c
- From: bmarzins@xxxxxxxxxxxxxx
- Re: mirrored device with thousand of mappingtableentries
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [RFC][PATCH] dm: improve read performance
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
- multipath-tools ./multipath.conf.defaults kpar ...
- From: bmarzins@xxxxxxxxxxxxxx
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Andrew Patterson <andrew.patterson@xxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: Charles Slivkoff <slivkoff@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Andrew Patterson <andrew.patterson@xxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Evgeniy Polyakov <zbr@xxxxxxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Chris Wright <chrisw@xxxxxxxxxxxx>
- Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
- Re: [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: Charles Slivkoff <slivkoff@xxxxxxx>
- [RFC PATCH 4/2] connector: update callbacks to use security_netlink_recv()
- From: Chris Wright <chrisw@xxxxxxxxxxxx>
- [RFC PATCH 3/2] security: update security_netlink_recv hook prototype
- From: Chris Wright <chrisw@xxxxxxxxxxxx>
- Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Chris Wright <chrisw@xxxxxxxxxxxx>
- [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Chris Wright <chrisw@xxxxxxxxxxxx>
- Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
- From: James Morris <jmorris@xxxxxxxxx>
- Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
- From: David Miller <davem@xxxxxxxxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal
- From: <Yanqing_Liu@xxxxxxxx>
- Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Chris Wright <chrisw@xxxxxxxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: <Menny_Hamburger@xxxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: Charles Slivkoff <slivkoff@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Re: Huge memory allocation
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
- From: Patrick McHardy <kaber@xxxxxxxxx>
- Re: Huge memory allocation
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: Huge memory allocation
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Can I add an extent to en existing linear table?
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: Huge memory allocation
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: Charles Slivkoff <slivkoff@xxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: Charles Slivkoff <slivkoff@xxxxxxx>
- Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- How to change the size of a snapshot device?
- From: Greg Stark <stark@xxxxxxx>
- How to resize a snapshot to hold a larger filesystem
- From: Greg Stark <stark@xxxxxxx>
- [PATCH] multipath: Retry host transient errors for rdac checker
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
- From: Charles Slivkoff <slivkoff@xxxxxxx>
- Re: Huge memory allocation
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Huge memory allocation
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: clustered snapshots status, LVM on shared storage without CLVM?
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- clustered snapshots status, LVM on shared storage without CLVM?
- From: Nikola Ciprich <extmaillist@xxxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: mirrored device with thousand of mappingtableentries
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: mirrored device with thousand of mapping tableentries
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: mirrored device with thousand of mapping tableentries
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: mirrored device with thousand of mapping table entries
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- mirrored device with thousand of mapping table entries
- From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
- Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
- From: Eddie Williams <Eddie.Williams@xxxxxxxxxxx>
- Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
- From: Eddie Williams <Eddie.Williams@xxxxxxxxxxx>
- Re: call for slideware ;)
- From: Joe Thornber <thornber@xxxxxxxxxx>
- Re: call for slideware ;)
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: call for slideware ;)
- From: Joe Thornber <thornber@xxxxxxxxxx>
- Re: call for slideware ;)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: call for slideware ;)
- From: Joe Thornber <thornber@xxxxxxxxxx>
- Where can I get thin provisioning target sources?
- From: xiaoli zhu <xiao001li@xxxxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- dm_mod crashed while adding new luns into multipath
- From: "Janec, Jozef" <jozef.janec@xxxxxx>
- Re: What is the deal with the partition separator?
- From: Phillip Susi <psusi@xxxxxxxxxx>
- multipath-tools ./multipath.conf.annotated lib ...
- From: bmarzins@xxxxxxxxxxxxxx
- Re: timestamp for shared snapshot
- From: devicemapper niko <devicemapper.niko@xxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH] Fix over-zealous flush_disk when changing device size.
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Curtis Gedak <gedakc@xxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: What is the deal with the partition separator?
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Linux DMM Questions
- From: "CHANDRASEKARAN, GIRIDHAR (GIRI) (ATTSI)" <gs3162@xxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxx>
- Re: What is the deal with the partition separator?
- From: Hannes Reinecke <hare@xxxxxxx>
- [PATCH] Fix over-zealous flush_disk when changing device size.
- From: NeilBrown <neilb@xxxxxxx>
- Re: What is the deal with the partition separator?
- From: Curtis Gedak <gedakc@xxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Curtis Gedak <gedakc@xxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Phillip Susi <psusi@xxxxxxxxxx>
- multipath-tools/libmultipath configure.c struc ...
- From: bmarzins@xxxxxxxxxxxxxx
- Re: timestamp for shared snapshot
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- [PATCH] Use only specific errors when failing dm-ioctl
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxx>
- Re: timestamp for shared snapshot
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- timestamp for shared snapshot
- From: devicemapper niko <devicemapper.niko@xxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: What is the deal with the partition separator?
- From: Hannes Reinecke <hare@xxxxxxx>
- What is the deal with the partition separator?
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH] Return EROFS if read-only detected on block device
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] Propagate device open error to table constructor.
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: NeilBrown <neilb@xxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH] loop: clear read-only flag in loop_clr_fd.
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH] loop: clear read-only flag in loop_clr_fd.
- From: Milan Broz <mbroz@xxxxxxxxxx>
- What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware? dmraid -rD output
- From: "rkliese@xxxxxx" <rkliese@xxxxxx>
- Re: multipath: partitions are not created on IBM 1746 (SAS connection to DS3512)
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: multipath: partitions are not created on IBM 1746 (SAS connection to DS3512)
- From: Peter Volkov <peter.volkov@xxxxxxxxx>
- [PATCH v2] scsi_dh_rdac : Adding MODULE VERSION for rdac device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH v2] [SCSI] fix kzalloc in scsi device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH} scsi_dh_rdac: fix for lun_table update for rdac device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/2 v2] dm mpath: allow table load with 0 priority groups
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 2/2 v2] dm mpath: allow table load with 0 priority groups
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dd slow while reading on multipathing, writing is fast
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- [PATCH]: multipath: fail path on zero size devices
- From: <Menny_Hamburger@xxxxxxxx>
- Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxx>
- Re: dd slow while reading on multipathing, writing is fast
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: dd slow while reading on multipathing, writing is fast
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Peter Volkov <peter.volkov@xxxxxxxxx>
- dd slow while reading on multipathing, writing is fast
- From: bart.coninckx@xxxxxxxxxx
- Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Peter Volkov <peter.volkov@xxxxxxxxx>
- Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH 1/3] dm crypt: wipe keys string immediately after key is set
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 3/3] dm ioctl: add data secure (bufer wipe) flag
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/3] dm ioctl: tidy code for next change
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: <Menny_Hamburger@xxxxxxxx>
- Re: Using the dm tools to create a writable "mirror" of a physical disk
- From: Phillip Susi <psusi@xxxxxxxxxx>
- [PATCH 3/3] dm ioctl: add data secure (bufer wipe) flag
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 2/3] dm ioctl: tidy code for next change
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 1/3] dm crypt: wipe keys string immediately after key is set
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Using the dm tools to create a writable "mirror" of a physical disk
- From: Anders Andersson <pipatron@xxxxxxxxx>
- [PATCH] add -r to make resulting device read-only
- From: Ritesh Raj Sarraf <rrs@xxxxxxxxxxxxxx>
- Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: Possible severe bug in the device mapper?
- From: Andreas Heinlein <aheinlein@xxxxxxx>
- Re: Possible severe bug in the device mapper?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Possible severe bug in the device mapper?
- From: Joe Thornber <thornber@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Possible severe bug in the device mapper?
- From: Andreas Heinlein <aheinlein@xxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: <Menny_Hamburger@xxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0 (was: Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 2/2] dm mpath: allow table load with 0 priority groups
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 1/2] dm mpath: fail message ioctl if specified path is not valid
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: Possible severe bug in the device mapper?
- From: Joe Thornber <thornber@xxxxxxxxxx>
- Re: Possible severe bug in the device mapper?
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Possible severe bug in the device mapper?
- From: Andreas Heinlein <aheinlein@xxxxxxx>
- Re: How to test the read/write flow of dm-target.
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: How to test the read/write flow of dm-target.
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: <Menny_Hamburger@xxxxxxxx>
- How to find last sector of bio.
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- Re: How to test the read/write flow of dm-target.
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Doubt regarding dm-raid1
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Doubt regarding dm-raid1
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- How to test the read/write flow of dm-target.
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- Re: Improving dm-mirror as a final year project
- From: nishant mungse <nishantmungse@xxxxxxxxx>
- Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
- Re: Announcement: new device-mapper thin provisioning target with infrastructure online for review
- From: Joe Thornber <thornber@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
- Re: Announcement: new device-mapper thin provisioning target with infrastructure online for review
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Announcement: new device-mapper thin provisioning target with infrastructure online for review
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: multipath - reference count on pgpath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: multipath - reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
- Re: [PATCH] multipath: reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
- [PATCH] multipath: reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
- multipath - reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- multipath-tools ./multipath.conf.defaults libm ...
- From: bmarzins@xxxxxxxxxxxxxx
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath
- From: Hannes Reinecke <hare@xxxxxxx>
- [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [PATCH 14/49] drivers/md: Use vzalloc
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: help:"event number"
- From: tom z <maillist.tom@xxxxxxxxx>
- Re: help:"event number"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- help:"event number"
- From: tom z <maillist.tom@xxxxxxxxx>
- Re: [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
- Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware?
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: [PATCH] block: restore multiple bd_link_disk_holder() support
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: training mpath to discern between SCSI errors
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [RFC PATCH 0/3] differentiate between I/O errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH] Documentation: dm-crypt: update cryptsetup homepage
- From: Jiri Kosina <jkosina@xxxxxxx>
- [PATCH] Documentation: dm-crypt: update cryptsetup homepage
- From: Andrea Gelmini <andrea.gelmini@xxxxxxxxx>
- Re: [PATCH] Documentation: dm-crypt: update cryptsetup homepage
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Ted Ts'o" <tytso@xxxxxxx>
- [git pull] device-mapper patches for 2.6.38
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: NeilBrown <neilb@xxxxxxx>
- Re: [PATCH] block: restore multiple bd_link_disk_holder() support
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] block: restore multiple bd_link_disk_holder() support
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Theodore Tso <tytso@xxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: linux-next: Tree for January 12 (dm-crypt)
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware?
- From: Mantas Kriaučiūnas <mantas@xxxxxx>
- Fw: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: NeilBrown <neilb@xxxxxxx>
- Re: linux-next: Tree for January 12 (dm-crypt)
- From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
- Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: Justin Mattock <justinmattock@xxxxxxxxx>
- Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v4] dm mpath: delay retry of activate_path on SCSI_DH_RETRY
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: PROBLEM: SSD access time with dm-crypt is way too high
- From: Yakov Hrebtov <hrebtov@xxxxxxxxx>
- Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Michael Zugelder <michaelzugelder@xxxxxxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: trim support (discard)
- From: Jens Kasten <jens@xxxxxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: NeilBrown <neilb@xxxxxxx>
- Re: PROBLEM: SSD access time with dm-crypt is way too high
- From: Milan Broz <mbroz@xxxxxxxxxx>
- PROBLEM: SSD access time with dm-crypt is way too high
- From: Michael Zugelder <michaelzugelder@xxxxxxxxxxxxxx>
- Re: trim support (discard)
- From: Milan Broz <mbroz@xxxxxxxxxx>
- trim support (discard)
- From: Jens Kasten <jens@xxxxxxxxxxxxx>
- Re: kobject_put vs module unload
- From: Greg KH <gregkh@xxxxxxx>
- Re: kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: kobject_put vs module unload
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Re: kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: kobject_put vs module unload
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent) by fsync
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent) by fsync
- From: Christoph Hellwig <hch@xxxxxx>
- Re: kobject_put vs module unload
- From: Greg KH <gregkh@xxxxxxx>
- kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 6/6] dm-snap-persistent: make metadata_wq multithreaded
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent) by fsync
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- [PATCH v2] dm log: use PTR_ERR value instead of -ENOMEM
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [patch] md/dm-log: use PTR_ERR value instead of -ENOMEM
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH v2] dm snapshot: avoid storing private suspended state
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2] dm: remove superfluous irq disablement in dm_request_fn
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3] dm mpath: delay retry of activate_path on SCSI_DH_RETRY
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxxxxxxxxx>
- [PATCH 1/3] dm crypt: add post IV call to IV generator
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 2/3] dm crypt: add multi-key capability
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 3/3] dm crypt: add Loop-AES IV generator
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 0/3 v2] dm crypt: add Loop-AES compatibility mode support
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] dm: move device check warning messages into debug level
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: NeilBrown <neilb@xxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] Make kcopyd merge more I/O requests
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Steven Whitehouse <swhiteho@xxxxxxxxxx>
- Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Tejun Heo <tj@xxxxxxxxxx>
- Refcounting (and other) questions
- From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
- [RFC][PATCH] dm: improve read performance
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
- Re: [RFC][PATCH] dm: improve read performance
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
- Re: [RFC][PATCH] dm: improve read performance
- From: Neil Brown <neilb@xxxxxxx>
- [PATCH 4/7] dm crypt: remove unused compatible table output
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 6/7] [RFC]dm crypt: add multi-key capability
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 7/7] [RFC]dm crypt: add loop-aes LMK IV generator
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 2/7] dm crypt: remove redundant setkey call
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 5/7] dm crypt: redefine IV generator function and add post IV call
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 3/7] dm crypt: set key size early
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 0/7] dm crypt fixes and loop-aes mode support
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 1/7] dm crypt: fix per cpu struct dereference in destructor
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH v3 3/8] md/raid5: use sysfs_notify_dirent_safe to avoid NULL pointer
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Neil Brown <neilb@xxxxxxx>
- [PATCH v3 4/8] dm raid: skeleton raid456 target support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 2/8] md/bitmap: use DIV_ROUND_UP in bitmap_init_from_disk
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 7/8] dm raid: add iterate_devices and io_hints functions
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 6/8] dm: per-target unplug callback support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 5/8] dm: introduce target callbacks and congestion callback
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 8/8] dm raid: add suspend and resume functions
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 1/8] md/bitmap: revert dm-dirty-log preparation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 0/8] dm-raid (raid456) target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
- BUG after md/raid10:md0: not enough operational mirrors.
- From: Ilia Mirkin <imirkin@xxxxxxxxxxxx>
- Re: dm: update workqueue usages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [ANNOUNCE] cryptsetup 1.2.0
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] multipath: add allow users to set revision in multipath.conf
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- mpath_ctl syntax
- From: Miles Taylor <Miles.Taylor@xxxxxxxxxxxx>
- Trying to figure out how/whether to use device mapper with bcache
- From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
- Re: reproducer for DM on MD flush deadlock? (was: Re: [PULL REQUEST] md bug fixes)
- From: Neil Brown <neilb@xxxxxxx>
- reproducer for DM on MD flush deadlock? (was: Re: [PULL REQUEST] md bug fixes)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v3][SCSI] scsi_dh: propagate SCSI device deletion
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH][rfc] md: Close mem leak in userspace_ctr()
- From: Jesper Juhl <jj@xxxxxxxxxxxxx>
- Re: training mpath to discern between SCSI errors
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [PATCH for-2.6.37] block: max hardware sectors limit wrapper
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- Re: [PATCH for-2.6.37] block: max hardware sectors limit wrapper
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- [PATCH v3][SCSI] scsi_dh: propagate SCSI device deletion
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: <Menny_Hamburger@xxxxxxxx>
- Re: [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: <Menny_Hamburger@xxxxxxxx>
- [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
- Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Dave Chinner <david@xxxxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [Patch 1 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
- [Patch 1 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
- Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH][rfc] md: Close mem leak in userspace_ctr()
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 4 of 8] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 8 of 8] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 7 of 8] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 6 of 8] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 3 of 8] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 2 of 8] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 1 of 8] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 5 of 8] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 0 of 8] DM RAID: a wrapper target for MD RAID456 (skeleton)
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: dm: update workqueue usages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCHSET] dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH][rfc] md: Close mem leak in userspace_ctr()
- From: Jesper Juhl <jj@xxxxxxxxxxxxx>
- Re: [PATCHSET] dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCHSET] dm: update workqueue usages
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
- Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- dm-devel] [PATCH 1/1]: dm+dh: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
- [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
- Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: [PATCHSET] dm: update workqueue usages
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH 5/6] dm: use non-reentrant workqueues if equivalent
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 4/6] dm: don't use flush_scheduled_work()
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 6/6] dm-snap-persistent: make metadata_wq multithreaded
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 1/6] dm-stripe: drop kstriped
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 3/6] dm-snap: convert to alloc[_ordered]_workqueue()
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCHSET] dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 2/6] dm-snap: kill unused dm_snapshot->queued_bios_work and ksnapd
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: [RFC PATCH 0/3] differentiate between I/O errors
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- [PATCH <missing> of 8: MD new mddev flag value
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 8 of 8] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 6 of 8] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 7 of 8] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 5 of 8] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 4 of 8] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 3 of 8] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 2 of 8] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 1 of 8] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 0 of 8] DM RAID: a wrapper target for MD RAID456 (skeleton)
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Fedyk <mfedyk@xxxxxxxxxxxxx>
- Possible kpartx bug investigation/report
- From: Tarcisio Fedrizzi <tarcisio.fedrizzi@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- [RESEND][PATCH v2 1/4] dm log userspace: trap all errors from failed log construction
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
- Re: rdac.c patch not quite right.
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
- Re: rdac.c patch not quite right.
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- [PATCH v2 3/3] block: improve detail in I/O error messages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: [RFC PATCH 3/3] block: improve detail in I/O error messages
- From: Sergei Shtylyov <sshtylyov@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- [RFC PATCH 3/3] block: improve detail in I/O error messages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [RFC PATCH 0/3] differentiate between I/O errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [RFC PATCH v2 1/3] scsi: Detailed I/O errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [RFC PATCH v2 2/3] dm mpath: propagate target errors immediately
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH] multipath: add find_multipaths feature.
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [stable] QUEUE_FLAG_CLUSTER?
- From: Greg KH <greg@xxxxxxxxx>
- Re: rdac.c patch not quite right.
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- multipath-tools/multipathd main.c
- From: bmarzins@xxxxxxxxxxxxxx
- Re: multipathing in debian lenny with sychronized data between 2 servers
- From: Oliver Rojo <orojo.horus@xxxxxxxxx>
- Re: multipathing in debian lenny with sychronized data between 2 servers
- From: Oliver Rojo <orojo.horus@xxxxxxxxx>
- Re: multipathing in debian lenny with sychronized data between 2 servers
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- [PATCH for-2.6.37] block: max hardware sectors limit wrapper
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- multipathing in debian lenny with sychronized data between 2 servers
- From: Oliver Rojo <orojo.horus@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Daniel J Blueman <daniel.blueman@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Valdis.Kletnieks@xxxxxx
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Theodore Tso <tytso@xxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Heinz Diehl <htd@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Heinz Diehl <htd@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm: check max_sectors in dm_merge_bvec (was: Re: dm: max_segments=1 if merge_bvec_fn is not supported)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: [PATCH] dm: check max_sectors in dm_merge_bvec (was: Re: dm: max_segments=1 if merge_bvec_fn is not supported)
- From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
- [PATCH] dm: check max_sectors in dm_merge_bvec (was: Re: dm: max_segments=1 if merge_bvec_fn is not supported)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] multipath: make "show config" show the whole config.
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- [PATCH] multipath: standardize on path_selector
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- [PATCH] multipath: update multipathd man page
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- [PATCH v2 4/4] dm log userspace: add version number to communication structure
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 3/4] dm log userspace: group clear and mark requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 2/4] dm log userspace: split flush queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 0/4] dm log userspace: a fix and other improvements
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 1/4] dm log userspace: trap all errors from failed log construction
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- How about adding an include directive in multipath.conf file?
- From: Don Hoover <dxh@xxxxxxxxx>
- Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: Nick Piggin <npiggin@xxxxxxxxx>
- [PATCH 14 of 15] md new superblock type
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 15 of 15] md add bitmap support
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 13 of 15] dm raid allow metadata devices
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 12 of 15] md separate meta and data devs
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 11 of 15] md new param to_sync_page_io
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 9 of 15] dm raid message fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 10 of 15] md new param to calc_dev_sboffset
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 4 of 15] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 1 of 15] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 7 of 15] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 6 of 15] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 5 of 15] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 8 of 15] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 2 of 15] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 3 of 15] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- [PATCH 0 of 15] DM RAID: a wrapper target for MD RAID456
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
- Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
- Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/4] block: Measure flush round-trip times and report average value
- From: Lukas Czerner <lczerner@xxxxxxxxxx>
- hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Heinz Diehl <htd@xxxxxxxxxx>
- Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Matt <jackdachef@xxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm-crypt barrier support is effective
- From: Matt <jackdachef@xxxxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Mingming Cao <cmm@xxxxxxxxxx>
- Re: ioctl HDIO_GETGEO to device mapper devpath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: QUEUE_FLAG_CLUSTER?
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- multipath-tools/libmultipath discovery.c switc ...
- From: bmarzins@xxxxxxxxxxxxxx
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Ric Wheeler <rwheeler@xxxxxxxxxx>
- rdac.c patch not quite right.
- From: Chaskiel Grundman <cg2v@xxxxxxxxxxxxxx>
- Re: ioctl HDIO_GETGEO to device mapper devpath
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [PATCH 3/4] dm: Compute average flush time from component devices
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Ric Wheeler <rwheeler@xxxxxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- Re: Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Ric Wheeler <rwheeler@xxxxxxxxxx>
- [PATCH] dm crypt: use IO thread for reads only if mempool is exhausted
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] dm crypt: scale to multiple CPUs
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] dm: remove dm_mutex (after bkl conversion)
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [Multipath DOCS] Some possibly deprecated info
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- [PATCH 4/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- [PATCH 3/4] dm: Compute average flush time from component devices
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- [PATCH 1/4] block: Measure flush round-trip times and report average value
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- [PATCH 2/4] md: Compute average flush time from component devices
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
- ioctl HDIO_GETGEO to device mapper devpath
- From: Santosh Sarangi <santosh.sarangi1@xxxxxxxxx>
- [Multipath DOCS] Some possibly deprecated info
- From: Oren Held <orenhe@xxxxxxxxxx>
- discard/trim support in device mapper?
- From: Andreas Beckmann <beckmann@xxxxxxxxxxxxxxxxxxx>
- Re: Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: Rahsaan Page <rahsaan.page@xxxxxxxxx>
- Antw: Re: Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
[Index of Archives]
[DM Crypt]
[Fedora Desktop]
[ATA RAID]
[Fedora Marketing]
[Fedora Packaging]
[Fedora SELinux]
[Yosemite Discussion]
[KDE Users]
[Fedora Docs]