Linux Device-Mapper Development

• Thread Index

• [PATCH 08/18] Fix issues with user_friendly_names initramfs bindings
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 16/18] Increase host buffer size
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 02/18] fix memory leaks on realloc failures
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 07/18] make kpartx -d remove all partitions
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 09/18] Make multipath deactivate devices before iscsi shutdown
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 00/18] multipath patch sync
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 05/18] update multipath rules to deal with partition devices
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• Re: dm: reduce the number of processes per dm device
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm: reduce the number of processes per dm device
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH v2] block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2] block: flush queued bios when the process blocks
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Hard lockup in ext4_finish_bio
  • From: Nikolay Borisov <kernel@xxxxxxxx>
• Re: Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Next release plans?
  • From: Xose Vazquez Perez <xose.vazquez@xxxxxxxxx>
• Re: dm-multipath test scripts
  • From: Johannes Thumshirn <jthumshirn@xxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• dm-multipath test scripts
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH v2] block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH v2] block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH for v4.3-rc] dm: fix request-based dm error reporting
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] kpartx: use inode to identify loopback mounts
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx>
• Re: Unnecessary scanning of all SCSI devices in mpath_persistent_reserve_in/out command, sent to a specific mpath device,
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx>
• Re: [PATCH] libmultipath: Fix information not shown when first path is down.
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• [PATCH] libmultipath: Fix information not shown when first path is down.
  • From: Gabriel Krisman Bertazi <krisman@xxxxxxxxxxxxxxxxxx>
• [PATCH for v4.3-rc] dm: fix request-based dm error reporting
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: block: flush queued bios when the process blocks
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• [PATCH] dm ioctl: use kvfree() in free_params()
  • From: Geliang Tang <geliangtang@xxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• [PATCH 2/5] fs: Treat foreign mounts as nosuid
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• [PATCH 3/5] selinux: Add support for unprivileged mounts from user namespaces
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• [PATCH 4/5] userns: Replace in_userns with current_in_userns
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• [PATCH 0/5] User namespace mount updates
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• [PATCH 5/5] Smack: Handle labels consistently in untrusted mounts
  • From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx>
• dm-cache always dirty in writethrough mode
  • From: sbp <sbp@xxxxxxxx>
• [PATCH] dm: convert ffs to __ffs
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm-raid: fix default region size
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: dm: fix AB-BA deadlock in __dm_destroy()
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Jan Kara <jack@xxxxxxx>
• Re: dm: fix AB-BA deadlock in __dm_destroy()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] crash in md-raid1 and md-raid10 due to incorrect list manipulation
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm: fix AB-BA deadlock in __dm_destroy()
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• [PATCH] dm: fix AB-BA deadlock in __dm_destroy()
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH 1/5] fs: Verify access of user towards block device file when mounting
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Neil Brown <neilb@xxxxxxx>
• Re: Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Brassow Jonathan <jbrassow@xxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Queuing of dm-raid1 resyncs to the same underlying block devices
  • From: Richard Davies <richard@xxxxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: v4.3-rc2 dm-mq bug
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• v4.3-rc2 dm-mq bug
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• multipath with alias and binding file
  • From: "Schunack, Daniel" <dschunack@xxxxxx>
• [git pull] device mapper fixes for 4.3-rc3
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Severe performance degradation for dm-cache mq since c86c3070
  • From: Andrey Korolyov <andrey@xxxxxxx>
• Re: [PATCH 5/5] block: Inline blk_integrity in struct gendisk
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: Severe performance degradation for dm-cache mq since c86c3070
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [PATCH 1/5] block: Move integrity kobject to struct gendisk
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [PATCH 5/5] block: Inline blk_integrity in struct gendisk
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: dm: ioctl: prevent double freeing
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm: ioctl: prevent double freeing
  • From: "Darrick J. Wong" <darrick.wong@xxxxxxxxxx>
• Re: [PATCH] dm: ioctl: prevent double freeing
  • From: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>
• Re: [PATCH 12/39] dm: drop null test before destroy functions
  • From: Julia Lawall <julia.lawall@xxxxxxx>
• Re: [PATCH 12/39] dm: drop null test before destroy functions
  • From: walter harms <wharms@xxxxxx>
• Re: [PATCH 12/39] dm: drop null test before destroy functions
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 12/39] dm: drop null test before destroy functions
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 12/39] dm: drop null test before destroy functions
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: Severe performance degradation for dm-cache mq since c86c3070
  • From: Andrey Korolyov <andrey@xxxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: James Bottomley <jbottomley@xxxxxxxx>
• [PATCH 12/39] dm: drop null test before destroy functions
  • From: Julia Lawall <Julia.Lawall@xxxxxxx>
• How do you force-close a dm device?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: Severe performance degradation for dm-cache mq since c86c3070
  • From: Andrey Korolyov <andrey@xxxxxxx>
• Re: How do you force-close a dm device after a disk failure?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• How do you force-close a dm device after a disk failure?
  • From: Adam Nielsen <a.nielsen@xxxxxxxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Regression: Disk corruption with dm-crypt and kernels >= 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Severe performance degradation for dm-cache mq since c86c3070
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Severe performance degradation for dm-cache mq since c86c3070
  • From: Andrey Korolyov <andrey@xxxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: James Bottomley <jbottomley@xxxxxxxx>
• randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: Jim Davis <jim.epost@xxxxxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Dave Chinner <dchinner@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Dave Chinner <dchinner@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Dave Chinner <dchinner@xxxxxxxxxx>
• [PATCH] dm: ioctl: prevent double freeing
  • From: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: udev rules do not create partition entries when an lvm lv is partitioned
  • From: Joe Julian <me@xxxxxxxxxxxxxx>
• Re: udev rules do not create partition entries when an lvm lv is partitioned
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• udev rules do not create partition entries when an lvm lv is partitioned
  • From: Joe Julian <me@xxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Dave Chinner <dchinner@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Dave Chinner <dchinner@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Dave Chinner <dchinner@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Pekka Enberg <penberg@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Pekka Enberg <penberg@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Christoph Lameter <cl@xxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [git pull] device mapper changes for 4.3
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 1/2] mm/slab_common: add SLAB_NO_MERGE flag for use when creating slabs
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• [PATCH 2/2] dm: disable slab merging for all DM slabs
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 1/2] mm/slab_common: add SLAB_NO_MERGE flag for use when creating slabs
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• D-Bus API for multipath
  • From: Todd Gill <tgill@xxxxxxxxxx>
• Re: dm-delay: Add a message to change delay
  • From: Andy Grover <agrover@xxxxxxxxxx>
• Re: dm-delay: Add a message to change delay
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm-delay: Add a message to change delay
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH] dm-delay: Add a message to change delay
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [PATCH] dm-delay: Add a message to change delay
  • From: Andy Grover <agrover@xxxxxxxxxx>
• Re: [PATCH] dm-delay: Add a message to change delay
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• [PATCH] dm-delay: Add a message to change delay
  • From: Andy Grover <agrover@xxxxxxxxxx>
• Re: [PATCH] dm btree: add ref counting ops for the leaves of top level btrees
  • From: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
• Re: Unnecessary scanning of all SCSI devices in mpath_persistent_reserve_in/out command, sent to a specific mpath device,
  • From: Satyajit Deshmukh <satyajit.s.deshmukh@xxxxxxxxx>
• Re: Persistent Reservation API V3
  • From: Jeremy Linton <jlinton@xxxxxxxxxxxxx>
• Issue with DM Multipath reconfigure command
  • From: Sharath Babu <sharath.babu@xxxxxxxxxx>
• Duplicate multipathd process
  • From: Juliano da Costa <juliano.dacosta@xxxxxxxxx>
• [PATCH 0/4] dm-latency: Introduction
  • From: Coly Li <i@xxxxxxx>
• Re: Persistent Reservation API V3
  • From: Christoph Hellwig <hch@xxxxxx>
• Unnecessary scanning of all SCSI devices in mpath_persistent_reserve_in/out command, sent to a specific mpath device,
  • From: Satyajit Deshmukh <satyajit.s.deshmukh@xxxxxxxxx>
• [PATCH 4/5] dm: refactor ioctl handling
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 1/5] block: cleanup blkdev_ioctl
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 2/5] block: add an API for Persistent Reservations
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 3/5] sd: implement the Persistent Reservation API
  • From: Christoph Hellwig <hch@xxxxxx>
• Persistent Reservation API V3
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 5/5] dm: add support for passing through persistent reservations
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: Persistent Reservation API V3
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Persistent Reservation API V3
  • From: Christoph Hellwig <hch@xxxxxx>
• Persistent Reservation API V3
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 1/5] block: cleanup blkdev_ioctl
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: Possible bug when redistributing entries between dm-btree node
  • From: Dennis Yang <shinrairis@xxxxxxxxx>
• Possibly weird behavior with mpath_persist on CentOS 6.6 (device-mapper-multipath-0.4.9...)
  • From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
• [PATCH v2] dm-raid.txt: document discard support
  • From: heinzm@xxxxxxxxxx
• Possible bug when redistributing entries between dm-btree node
  • From: Dennis Yang <shinrairis@xxxxxxxxx>
• Re: A small question about Device Mapper
  • From: "Ni, Xun" <xun.ni@xxxxxxxxx>
• Re: A small question about Device Mapper
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: A small question about Device Mapper
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• A small question about Device Mapper
  • From: "Ni, Xun" <xun.ni@xxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: Persistent Reservation API V2
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: multipathd removing DM devices that don't belong to it
  • From: Artem Danielov <artem@xxxxxxxxxxxx>
• multipath -f with friendly names doesn't flush
  • From: "Walter A. Boring IV" <walter.boring@xxxxxx>
• Re: Persistent Reservation API V2
  • From: Keith Busch <keith.busch@xxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm btree: add ref counting ops for the leaves of top level btrees
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm-cache suspend semantics
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• dm-cache suspend semantics
  • From: Thanos Makatos <thanos.makatos@xxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: [PATCH] dm-statistics: report precise timestamps and histogram
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: Any device mapper target that stores data in files?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: Persistent Reservation API V2
  • From: Jens Axboe <axboe@xxxxxx>
• Re: Any device mapper target that stores data in files?
  • From: Thiago Padilha <tpadilha84@xxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: dm-statistics: report precise timestamps and histogram
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm-statistics: report precise timestamps and histogram
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: Any device mapper target that stores data in files?
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: Persistent Reservation API V2
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Any device mapper target that stores data in files?
  • From: Thiago Padilha <tpadilha84@xxxxxxxxx>
• [git pull] device mapper fixes for 4.2-rc7
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm-raid.txt: document discard support
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] device mapper support for strace
  • From: Mike Frysinger <vapier@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: DM above MD raid5
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-raid.txt: document discard support
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• [PATCH] dm cache policy smq: mv module alias: dm-cache-default to SMQ
  • From: Yi Zhang <yizhan@xxxxxxxxxx>
• [PATCH v6 08/11] block: kill merge_bvec_fn() completely
  • From: Ming Lin <mlin@xxxxxxxxxx>
• [PATCH v6 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• [PATCH 1/5] block: cleanup blkdev_ioctl
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 5/5] dm: add support for passing through persistent reservations
  • From: Christoph Hellwig <hch@xxxxxx>
• Persistent Reservation API V2
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 4/5] dm: refactor ioctl handling
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 2/5] block: add an API for Persistent Reservations
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 3/5] sd: implement the Persistent Reservation API
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH 3/6] sd: implement the persisten reservation API
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH 2/6] block: add a API for persistent reservations
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH 1/6] block: cleanup blkdev_ioctl
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH] block: don't access bio->bi_error after bio_put()
  • From: Jens Axboe <axboe@xxxxxxxxx>
• DM above MD raid5
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: [PATCH] device mapper support for strace
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] block: don't access bio->bi_error after bio_put()
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: dm-dedup: freeze and panic
  • From: Vincent Donnefort <vdonnefort@xxxxxxxxx>
• Re: dm-snap deadlock in pending_complete()
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] block: don't access bio->bi_error after bio_put()
  • From: Sasha Levin <sasha.levin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• Re: [PATCH V1 Resend 04/11] drivers: md: Drop unlikely before IS_ERR(_OR_NULL)
  • From: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH V1 Resend 04/11] drivers: md: Drop unlikely before IS_ERR(_OR_NULL)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH V1 Resend 04/11] drivers: md: Drop unlikely before IS_ERR(_OR_NULL)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] fs/block_dev.c: Remove WARN_ON() when inode writeback fails
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH V1 Resend 04/11] drivers: md: Drop unlikely before IS_ERR(_OR_NULL)
  • From: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• dm-snap deadlock in pending_complete()
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH] dm-raid.txt: document discard support
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• [git pull] device mapper fixes for 4.2-rc6
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm-cache with a very slow device
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: multipath-tools: symlinks and block devices in /dev/mapper
  • From: Xose Vazquez Perez <xose.vazquez@xxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• dm-cache with a very slow device
  • From: Lauri Niskanen <ape@xxxxxxxxxxx>
• Re: kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4->RAID0) device
  • From: NeilBrown <neilb@xxxxxxxx>
• multipath-tools: symlinks and block devices in /dev/mapper
  • From: "Stewart, Sean" <Sean.Stewart@xxxxxxxxxx>
• Re: [PATCH 5/6] dm: split out a helper to find the ioctl target
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH] dm-raid.txt: document discard support
  • From: heinzm@xxxxxxxxxx
• Re: [PATCH 4/6] dm: refactor ioctl handling
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: Persistent Reservation API
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: Persistent Reservation API
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4->RAID0) device
  • From: Yi Zhang <yizhan@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH 5/6] dm: split out a helper to find the ioctl target
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Persistent Reservation API
  • From: Keith Busch <keith.busch@xxxxxxxxx>
• Re: [PATCH 4/6] dm: refactor ioctl handling
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Persistent Reservation API
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 1/6] block: cleanup blkdev_ioctl
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 5/6] dm: split out a helper to find the ioctl target
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 2/6] block: add a API for persistent reservations
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 4/6] dm: refactor ioctl handling
  • From: Christoph Hellwig <hch@xxxxxx>
• Persistent Reservation API
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 3/6] sd: implement the persisten reservation API
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 6/6] dm: add support for passing through persistent reservations
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• [PATCH 06/15] drivers: md: Drop unlikely before IS_ERR(_OR_NULL)
  • From: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: [PATCH] device mapper support for strace
  • From: "Dmitry V. Levin" <ldv@xxxxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: [PATCH] device mapper support for strace
  • From: "Dmitry V. Levin" <ldv@xxxxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] device mapper support for strace
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] device mapper support for strace
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 1/1] device-mapper: Do not override error code from dm_get_device()
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• lvconvert leaves devices unsynced and unpolled?
  • From: Greg Stark <stark@xxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4->RAID0) device
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: Unnecessary snapshot validation
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Unnecessary snapshot validation
  • From: Frederick Grose <fgrose@xxxxxxxxx>
• Re: kernel BUG at drivers/scsi/scsi_lib.c:1101! observed during md5sum for one file on (RAID4->RAID0) device
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• [git pull] device mapper fixes for 4.2-rc5
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Liu Bo <bo.li.liu@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: [PATCH v2 3/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Ondrej Kozina <okozina@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
  • From: Andreas Hartmann <andihartmann@xxxxxxxxxxxxxxx>
• DMCache Desing Questions
  • From: Leonardo Santos <heiligerstein@xxxxxxxxx>
• Re: [PATCH v2 3/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: dm cache: fix alloc_bitset check that always evaluates as false
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm: crypt: update wiki page URL
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: linux-4.2-rc4/drivers/md/dm-cache-policy-smq.c:1689: bad if test ?
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: multipathd removing DM devices that don't belong to it
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
• Re: multipathd removing DM devices that don't belong to it
  • From: Artem Danielov <artem@xxxxxxxxxxxx>
• linux-4.2-rc4/drivers/md/dm-cache-policy-smq.c:1689: bad if test ?
  • From: David Binderman <dcb314@xxxxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH] dm: crypt: update wiki page URL
  • From: Baruch Siach <baruch@xxxxxxxxxx>
• [PATCH] dm cache: fix alloc_bitset check that always evaluates as false
  • From: Colin King <colin.king@xxxxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• [RFC PATCH] block: dm thin: export how block device handles -ENOSPC
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Jens Axboe <axboe@xxxxxxxxx>
• DM dtr activation context
  • From: <gilib123@xxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• Re: DM-Cache Writeback & Direct IO?
  • From: Christoph Nelles <evilazrael@xxxxxxxxxxxxx>
• Re: back-ported dm-cache not forwarding read-ahead bios to origin
  • From: Thanos Makatos <thanos.makatos@xxxxxxxxx>
• Re: [PATCH] block: add a bi_error field to struct bio
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] block: add a bi_error field to struct bio
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• [PATCH 2/2] multipathd: Disabled code that is not being used.
  • From: Tejaswini Poluri <tpoluri@xxxxxxxxxx>
• [PATCH 1/2] multipathd: Fixing add map functionality
  • From: Tejaswini Poluri <tpoluri@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• [PATCH] md:Check if call to thaw_bdev fails in unlock_fs
  • From: Nicholas Krause <xerofoify@xxxxxxxxx>
• Re: back-ported dm-cache not forwarding read-ahead bios to origin
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• back-ported dm-cache not forwarding read-ahead bios to origin
  • From: Thanos Makatos <thanos.makatos@xxxxxxxxx>
• [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• add a bi_error field to struct bio V3
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• Re: [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• Re: [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• [git pull] device mapper fixes for 4.2-rc3
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: reinstate path not working
  • From: Tejaswini Poluri <tejaswinipoluri3@xxxxxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx>
• Re: [dm:for-next 7/7] drivers/md/dm-cache-target.c:3585:37: error: 'pool' undeclared
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [dm:for-next 7/7] drivers/md/dm-cache-target.c:3585:37: error: 'pool' undeclared
  • From: kbuild test robot <fengguang.wu@xxxxxxxxx>
• Re: dm-mpath: always return reservation conflict
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] dm-mpath: always return reservation conflict
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH] dm-mpath: always return reservation conflict
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• [patch] mm: improve __GFP_NORETRY comment based on implementation
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: David Rientjes <rientjes@xxxxxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Re: [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH v5 00/11] simplify block layer based on immutable biovecs
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm: fix a crash due to incorrect cleanup sequence
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: reinstate path not working
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH] multipathd: add map feature fix
  • From: Tejaswini Poluri <tejaswinipoluri3@xxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: DM-Cache Writeback & Direct IO?
  • From: Christoph Nelles <evilazrael@xxxxxxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: DM-Cache Writeback & Direct IO?
  • From: Christoph Nelles <evilazrael@xxxxxxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: DM-Cache Writeback & Direct IO?
  • From: Leonardo Santos <heiligerstein@xxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: API for multi-segment atomic IO
  • From: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
• Re: reinstate path not working
  • From: Tejaswini Poluri <tejaswinipoluri3@xxxxxxxxx>
• Re: DM-Cache Writeback & Direct IO?
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: 4.1: 9a0e609e3fd ("dm: only run the queue on completion if ....") causes significant overhead in osq_lock on ext4/multipath
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• DM-Cache Writeback & Direct IO?
  • From: Christoph Nelles <evilazrael@xxxxxxxxxxxxx>
• 4.1: 9a0e609e3fd ("dm: only run the queue on completion if ....") causes significant overhead in osq_lock on ext4/multipath
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Gili B <gilib123@xxxxxxxxxxx>
• API for multi-segment atomic IO
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 7/7] dm: make dm_vcalloc use kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 4/7] dm: use kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 5/7] dm-thin: use kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 6/7] dm-stats: use kvmalloc_node
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 3/7] dm-ioctl: join flags DM_PARAMS_KMALLOC and DM_PARAMS_VMALLOC
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 1/7] mm/vmalloc: export __vmalloc_node_flags
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 0/7] mm: reliable memory allocation with kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm: crypt: update wiki page URL
  • From: Baruch Siach <baruch@xxxxxxxxxx>
• Re: [PATCH v2 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• [PATCH] kpartx: use inode to identify loopback mounts
  • From: Risto Kankkunen <risto.kankkunen@xxxxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Nikolay Borisov <n.borisov@xxxxxxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: Integrating new DM targets to LVM
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: reinstate path not working
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• [PATCH 0/2] Couple of minor code cleanups
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• [PATCH 1/2] Remove unused parameter in btree_split_sibling()
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• [PATCH 2/2] dm-btree-remove: Remove function get_nr_entries()
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 5/7] dm-thin: use dm_kvmalloc
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>
• Re: Integrating new DM targets to LVM
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: Getting mapped device namw
  • From: Nikolay Borisov <kernel@xxxxxxxx>
• Getting mapped device namw
  • From: Gili B <gilib123@xxxxxxxxxxx>
• [PATCH v5 08/11] block: kill merge_bvec_fn() completely
  • From: Ming Lin <mlin@xxxxxxxxxx>
• [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• Integrating new DM targets to LVM
  • From: Gili B <gilib123@xxxxxxxxxxx>
• [PATCH 7/7] dm: make dm_vcalloc use dm_kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 6/7] dm-stats: use dm_kvmalloc_node
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 5/7] dm-thin: use dm_kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 4/7] dm: introduce dm_kvmalloc
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 2/7] dm-stats: rename functions
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 3/7] mm/vmalloc: export __vmalloc_node_flags
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 0/7] reliable memory allocation and fix for bug 1225370
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 1/7] dm-ioctl: join flags DM_PARAMS_KMALLOC and DM_PARAMS_VMALLOC
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• thin metadata raw backup
  • From: Ilya Basin <basinilya@xxxxxxxxx>
• [PATCH] dm: test return value for DM_MAPIO_SUBMITTED
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: DM_CACHE_SMQ is experimental and enabled by default? (was: Re: dm cache: add stochastic-multi-queue (smq) policy)
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: reinstate path not working
  • From: Tejaswini Poluri <tejaswinipoluri3@xxxxxxxxx>
• Re: [PATCH 3.10, 3.14] dm snapshot: allocate a per-target structure for snapshot-origin target
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: reinstate path not working
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• Re: [GIT PULL] Core block IO bits for 4.2
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [lvm-devel] udev cookie on DM_DEVICE_RELOAD
  • From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
• Re: udev cookie on DM_DEVICE_RELOAD
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: Device Mapper Persistent Configuration
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: udev cookie on DM_DEVICE_RELOAD
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• udev cookie on DM_DEVICE_RELOAD
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] dm verity: remove unused mempool
  • From: Sami Tolvanen <samitolvanen@xxxxxxxxxx>
• Re: Device Mapper Persistent Configuration
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Re: Device Mapper Persistent Configuration
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Device Mapper Persistent Configuration
  • From: Gili B <gilib123@xxxxxxxxxxx>
• Stochastic-Multi-Queue Performance
  • From: Leonardo Santos <heiligerstein@xxxxxxxxx>
• [PATCH] Fixing the find_loop_by_file function to properly compare the filename by respecting the LO_NAME_SIZE.
  • From: Jorge Niedbalski <jorge.niedbalski@xxxxxxxxxxxxx>
• Re: DM_CACHE_SMQ is experimental and enabled by default? (was: Re: dm cache: add stochastic-multi-queue (smq) policy)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [git pull] device mapper fixes for 4.2-rc1
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• dm-dedup: freeze and panic
  • From: Vincent Donnefort <vdonnefort@xxxxxxxxx>
• Re: [GIT PULL] Core block IO bits for 4.2
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: reinstate path not working
  • From: Tejaswini Poluri <tejaswinipoluri3@xxxxxxxxx>
• Re: [GIT PULL] Core block IO bits for 4.2
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] Core block IO bits for 4.2
  • From: Junichi Nomura <j-nomura@xxxxxxxxxxxxx>
• Re: reinstate path not working
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• Re: 40% performance loss with multipath since kernel 3.12
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• 40% performance loss with multipath since kernel 3.12
  • From: Derick Swanepoel <dswanepoel@xxxxxxxxx>
• [git pull] device mapper changes for 4.2
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: General protection fault with ext4 - LVM - raid456 (Raid 6)
  • From: NeilBrown <neilb@xxxxxxxx>
• Re: failed command: WRITE FPDMA QUEUED, suspiciously on two different disks
  • From: Sami Farin <hvtaifwkbgefbaei@xxxxxxxxx>
• General protection fault with ext4 - LVM - raid456 (Raid 6)
  • From: Jouni Karvo <Jouni.Karvo@xxxxxx>
• Re: Persistent memory interface
  • From: "hch@xxxxxx" <hch@xxxxxx>
• Re: reinstate path not working
  • From: Tejaswini Poluri <tejaswinipoluri3@xxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: Persistent memory interface
  • From: "Verma, Vishal L" <vishal.l.verma@xxxxxxxxx>
• Re: Persistent memory interface
  • From: "Verma, Vishal L" <vishal.l.verma@xxxxxxxxx>
• Re: Persistent memory interface
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• possible bug with kpartx -d and absolute paths
  • From: Parke <parke.nexus@xxxxxxxxx>
• Re: Persistent memory interface
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: [PATCH] fs/block_dev.c: Remove WARN_ON() when inode writeback fails
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH] fs/block_dev.c: Remove WARN_ON() when inode writeback fails
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: Persistent memory interface
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: multipathd removing DM devices that don't belong to it
  • From: "Benjamin Marzinski" <bmarzins@xxxxxxxxxx>
• Re: 3.12.y: srcu warning during free_dev() with dm-multipath
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: 3.12.y: srcu warning during free_dev() with dm-multipath
  • From: Sebastian Parschauer <sebastian.riemer@xxxxxxxxxxxxxxxx>
• Re: 3.12.y: srcu warning during free_dev() with dm-multipath
  • From: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>
• Re: 3.12.y: srcu warning during free_dev() with dm-multipath
  • From: Sebastian Parschauer <sebastian.riemer@xxxxxxxxxxxxxxxx>
• [PATCH v2 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• [PATCH v2 3/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• Re: Persistent memory interface
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxxxx>
• [PATCH v2 1/3] PM suspend/hibernate: Call notifier after freezing processes
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• [PATCH v2 2/3] dm: Export function dm_suspend_md()
  • From: Pali Rohár <pali.rohar@xxxxxxxxx>
• Re: Persistent memory interface
  • From: "Verma, Vishal L" <vishal.l.verma@xxxxxxxxx>
• Re: Unnecessary snapshot validation
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Persistent memory interface
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Persistent memory interface
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Persistent memory interface
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Persistent memory interface
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• Re: Persistent memory interface
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: Persistent memory interface
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Persistent memory interface
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• WARNING: at fs/block_dev.c:5 when removing LV on removed device
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
  • From: Ming Lin <mlin@xxxxxxxxxx>
• 3.12.y: srcu warning during free_dev() with dm-multipath
  • From: Sebastian Parschauer <sebastian.riemer@xxxxxxxxxxxxxxxx>
• [dm:for-next 43/47] drivers/md/dm-cache-policy-smq.c:1751:36: error: redefinition of 'smq_policy_type'
  • From: kbuild test robot <fengguang.wu@xxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: [PATCH 0/4] Integrate dm-latency functionality to dm-statistics
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• multipathd removing DM devices that don't belong to it
  • From: Artem Danielov <artem@xxxxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Doug Dumitru <doug@xxxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Johannes Bauer <dfnsonfsduifb@xxxxxx>
• Re: [PATCH 3/4] dm stats: report histogram of latencies
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [PATCH 0/4] Integrate dm-latency functionality to dm-statistics
  • From: Coly Li <colyli@xxxxxxxxx>
• Re: [PATCH 2/4] dm stats: support precise timestamps
  • From: Coly Li <colyli@xxxxxxxxx>
• Re: [PATCH 3/4] dm stats: report histogram of latencies
  • From: Coly Li <colyli@xxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Minfei Huang <mnfhuang@xxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Minfei Huang <mnfhuang@xxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• [PATCH] dm-statistics: update documentation
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Newbie device mapper questions
  • From: Doug Dumitru <doug@xxxxxxxxxx>