Linux LVM
[Prev Page][Next Page]
- Re: Replace Drive in RAID6
- From: Adam Puleo <adam.puleo@xxxxxxxxxx>
- (resend) may bug: lvconvert reports "Insufficient free space" when doing "--replace"
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- may bug: lvconvert reports "Insufficient free space" when doing "--replace"
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Changing shared VG lock type
- From: Charles Koprowski <charles@xxxxxxxxxx>
- Re: Replace Drive in RAID6
- From: Adam Puleo <adam.puleo@xxxxxxxxxx>
- Re: Changing shared VG lock type
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Replace Drive in RAID6
- From: Andreas Schrägle <linux-lvm@xxxxxxxxx>
- Changing shared VG lock type
- From: Charles Koprowski <charles@xxxxxxxxxx>
- Re: logical volume usage type code, equivalent to GPT partition type GUID
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: logical volume usage type code, equivalent to GPT partition type GUID
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- logical volume usage type code, equivalent to GPT partition type GUID
- From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
- Re: Replace Drive in RAID6
- From: Roberto Fastec <roberto.fastec@xxxxxxxxx>
- Replace Drive in RAID6
- From: Adam Puleo <adam.puleo@xxxxxxxxxx>
- Re: "md/raid:mdX: cannot start dirty degraded array."
- From: Andreas Trottmann <andreas.trottmann@xxxxxxxxxxx>
- [PATCH 1/1] udev: use absolute path in rule
- From: Christian Hesse <list@xxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Help restoring a corrupted PV partition ( 18th )
- From: Brian McCullough <bdmc@xxxxxxxxxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Brian McCullough <bdmc@xxxxxxxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>
- Re: Help restoring a corrupted PV partition ( 18th )
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Recovering "broken" disk ( 17th )
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Help restoring a corrupted PV partition ( 18th )
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Recovering "broken" disk ( 17th )
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- "md/raid:mdX: cannot start dirty degraded array."
- From: Andreas Trottmann <andreas.trottmann@xxxxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Krzysztof Chojnowski <frirajder@xxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Ming Hung Tsai <mtsai@xxxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Krzysztof Chojnowski <frirajder@xxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Ming Hung Tsai <mtsai@xxxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Krzysztof Chojnowski <frirajder@xxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Ming Hung Tsai <mtsai@xxxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Krzysztof Chojnowski <frirajder@xxxxxxxxx>
- LVM cachepool inconsistency after power event
- From: Krzysztof Chojnowski <frirajder@xxxxxxxxx>
- Re: LVM cachepool inconsistency after power event
- From: Ming-Hung Tsai <mingnus@xxxxxxxxx>
- LVM cachepool inconsistency after power event
- From: Krzysztof Chojnowski <frirajder@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: alessandro macuz <alessandro.macuz@xxxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: alessandro macuz <alessandro.macuz@xxxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: vgchange -a n --sysinit hangs without udevd
- From: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>
- Re: " Failed to find physical volume <ZFS block device"
- From: alessandro macuz <alessandro.macuz@xxxxxxxxx>
- " Failed to find physical volume <ZFS block device"
- From: alessandro macuz <alessandro.macuz@xxxxxxxxx>
- Re: vgchange -a n --sysinit hangs without udevd
- From: Arkadiusz Miśkiewicz <arekm@xxxxxxxx>
- vgchange -a n --sysinit hangs without udevd
- From: Arkadiusz Miśkiewicz <arekm@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: LVM tools segfault since 2.03.12
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: LVM tools segfault since 2.03.12
- From: Jean-Michel Pollion <jmp-lvm2@xxxxxxxxx>
- Re: LVM tools segfault since 2.03.12
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: The size specified by "lvcreate -L" is not accurate
- From: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>
- Re: LVM tools segfault since 2.03.12
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: The size specified by "lvcreate -L" is not accurate
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- LVM tools segfault since 2.03.12
- From: Jean-Michel Pollion <jmp-lvm2@xxxxxxxxx>
- The size specified by "lvcreate -L" is not accurate
- From: "Yu, Mingli" <Mingli.Yu@xxxxxxxxxxxxx>
- Re: Mapping lvol off to pvol off
- From: Stuart D Gathman <stuart@xxxxxxxxxxx>
- Mapping lvol off to pvol off
- From: Chethan Seshadri <chethan_seshadri@xxxxxxxxx>
- Re: How to check if thin volume or snapshot was ever activated
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: How to check if thin volume or snapshot was ever activated
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: How to check if thin volume or snapshot was ever activated
- From: Ming-Hung Tsai <mingnus@xxxxxxxxx>
- Re: How to check if thin volume or snapshot was ever activated
- From: Ming-Hung Tsai <mingnus@xxxxxxxxx>
- How to check if thin volume or snapshot was ever activated
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Questions about monitoring, scrubbing & checking a LVM RAID5
- From: Martin Dünkelmann <nc-duenkekl3@xxxxxxxxxxxxx>
- Re: Questions about monitoring, scrubbing & checking a LVM RAID5
- From: David Teigland <teigland@xxxxxxxxxx>
- Questions about monitoring, scrubbing & checking a LVM RAID5
- From: Martin Dünkelmann <nc-duenkekl3@xxxxxxxxxxxxx>
- Re: [RFC PATCH] lvconvert: fix the size of log device when converting, from linear to mirror
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] toolcontext: fix double free (core dumped) issue
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- [RFC PATCH] lvconvert: fix the size of log device when converting, from linear to mirror
- From: Zhong Lidong <lidong.zhong@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- [RFC PATCH] lvconvert: fix the size of log device when converting from linear to mirror
- From: Zhong Lidong <lidong.zhong@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Does LVM have any plan/schedule to support btrfs in fsadm
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Does LVM have any plan/schedule to support btrfs in fsadm
- From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
- Re: pvscan --cache -aay $device does not activate LV with multiple "legs"
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- Re: pvscan --cache -aay $device does not activate LV with multiple "legs"
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- Re: pvscan --cache -aay $device does not activate LV with multiple "legs"
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- Re: pvscan --cache -aay $device does not activate LV with multiple "legs"
- From: David Teigland <teigland@xxxxxxxxxx>
- pvscan --cache -aay $device does not activate LV with multiple "legs"
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- Problem with pvscan --cache -aay $pv (lvm2-pvscan@.service) on raid type LV
- From: Tom Yan <tom.ty89@xxxxxxxxx>
- Re: Does LVM have any plan/schedule to support btrfs in fsadm
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Does LVM have any plan/schedule to support btrfs in fsadm
- From: Stuart D Gathman <stuart@xxxxxxxxxxx>
- Re: Does LVM have any plan/schedule to support btrfs in fsadm
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Does LVM have any plan/schedule to support btrfs in fsadm
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Does LVM have any plan/schedule to support btrfs in fsadm
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Possible Bug vgrename
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: Possible Bug vgrename
- From: David Teigland <teigland@xxxxxxxxxx>
- Possible Bug vgrename
- From: N <dundir@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Cached root filesystem LV causes excessive disk activity following (re)boot.
- From: "zxzorn@xxxxxxxxx" <zxzorn@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Martin Wilck <martin.wilck@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Discussion: performance issue on event activation mode
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Discussion: performance issue on event activation mode
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: RAID1 mirroring behavior when one disk is dead sometimes - why not just use random numbers ??
- From: Marc Weber <marco-oweber@xxxxxx>
- Re: RAID1 mirroring behavior when one disk is dead sometimes?
- From: Péter Sárközi <xmisterhu@xxxxxxxxx>
- RAID1 mirroring behavior when one disk is dead sometimes?
- From: Marc Weber <marco-oweber@xxxxxx>
- Re: Possible bug with concurrent RAID syncs on the same underlying devices
- From: Péter Sárközi <xmisterhu@xxxxxxxxx>
- Re: Possible bug with concurrent RAID syncs on the same underlying devices
- From: David Teigland <teigland@xxxxxxxxxx>
- Possible bug with concurrent RAID syncs on the same underlying devices
- From: Péter Sárközi <xmisterhu@xxxxxxxxx>
- Re: move dm-integrity metadata to another PV
- From: Erwin van Londen <erwin@xxxxxxxxxxxxxxxxxx>
- Re: move dm-integrity metadata to another PV
- From: Sebastian Bachmann <hello@xxxxxxx>
- Re: move dm-integrity metadata to another PV
- From: David Teigland <teigland@xxxxxxxxxx>
- move dm-integrity metadata to another PV
- From: Sebastian Bachmann <hello@xxxxxxx>
- Re: [PATCH] [PATCH] stable-2.02 - lvresize: deny operation on swap dev without force option
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [PATCH] [PATCH] stable-2.02 - lvresize: deny operation on swap dev without force option
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- [PATCH] [PATCH] stable-2.02 - lvresize: deny operation on swap dev without force option
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Oleksandr Natalenko <oleksandr@xxxxxxxxxx>
- Re: Removing bash as a dependency
- From: Nicholas Geovanis <nickgeovanis@xxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Christian Hesse <list@xxxxxxxx>
- Re: Removing bash as a dependency
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Martin Wilck <mwilck@xxxxxxxx>
- Removing bash as a dependency
- From: "Drew Westrick" <drewwestrick@xxxxxxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Martin Wilck <mwilck@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Martin Wilck <mwilck@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Oleksandr Natalenko <oleksandr@xxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Martin Wilck <mwilck@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Martin Wilck <mwilck@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Martin Wilck <mwilck@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: Christian Hesse <list@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [PATCH 1/1] pvscan: wait for udevd
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH 1/1] pvscan: wait for udevd
- From: Christian Hesse <list@xxxxxxxx>
- Re: 2.03 Volume readable by 2.02?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: 2.03 Volume readable by 2.02?
- From: "John L. Poole" <jlpoole56@xxxxxxxxx>
- Re: 2.03 Volume readable by 2.02?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- 2.03 Volume readable by 2.02?
- From: "John L. Poole" <jlpoole56@xxxxxxxxx>
- RFE: Convert standard LV to Thin and vice versa
- From: Johannes Nieß <linux@xxxxxxxxxxxxxxxxx>
- Re: there is a vgextend sagfault with missing pv which is resolved on master, can we backport it to 2.02 branch
- From: Songmin Li <lisongmin9@xxxxxxxxx>
- Re: Mirror allocation policy
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: Mirror allocation policy
- From: Phillip Susi <phill@xxxxxxxxxxxx>
- Re: Mirror allocation policy
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: Mirror allocation policy
- From: Phillip Susi <phill@xxxxxxxxxxxx>
- Re: Mirror allocation policy
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Mirror allocation policy
- From: Phillip Susi <phill@xxxxxxxxxxxx>
- Re: there is a vgextend sagfault with missing pv which is resolved on master, can we backport it to 2.02 branch
- From: David Teigland <teigland@xxxxxxxxxx>
- there is a vgextend sagfault with missing pv which is resolved on master, can we backport it to 2.02 branch
- From: Songmin Li <lisongmin9@xxxxxxxxx>
- Re: discuss: about master branch vgcreate parameter "--clustered"
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: discuss: about master branch vgcreate parameter "--clustered"
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- discuss: about master branch vgcreate parameter "--clustered"
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- suggestion: replace security_context_t with char *
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: Dennis Schridde <devurandom@xxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: Dennis Schridde <devurandom@xxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: Dennis Schridde <devurandom@xxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: Dennis Schridde <devurandom@xxxxxxx>
- cache_check --clear-needs-check-flag does not clear needs_check flag?
- From: Dennis Schridde <devurandom@xxxxxxx>
- Re: System completely unstable after migrating to thin pools
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: System completely unstable after migrating to thin pools
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: System completely unstable after migrating to thin pools
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: listserver dropping posts? was: Search in the list
- From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
- Re: swap on thin-provisioning
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: swap on thin-provisioning
- From: Nicholas Geovanis <nickgeovanis@xxxxxxxxx>
- Re: swap on thin-provisioning
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Search in the list
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- System completely unstable after migrating to thin pools
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Search in the list
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- listserver dropping posts? was: Search in the list
- From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
- Re: swap on thin-provisioning
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- swap on thin-provisioning
- From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
- Re: Search in the list
- From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
- Search in the list
- From: Ilia Zykov <mail@xxxxxxx>
- Re: Is TRIM and DISCARD needed for normal HDD ?
- From: Marek Podmaka <marki@xxxxxxxxxxxxxxxx>
- Re: Is TRIM and DISCARD needed for normal HDD ?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Is TRIM and DISCARD needed for normal HDD ?
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: System bricked after moving to thin snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: System bricked after moving to thin snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: System bricked after moving to thin snapshots
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- System bricked after moving to thin snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- What is the use of thin snapshots if the external origin cannot be set to writable ?
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: Unusually long boot times with LVM Snapshots
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Unusually long boot times with LVM Snapshots
- From: Sreyan Chakravarty <sreyan32@xxxxxxxxx>
- Re: discussion about activation/auto_activation_volume_list
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: discussion about activation/auto_activation_volume_list
- From: Gang He <ghe@xxxxxxxx>
- Re: discussion about activation/auto_activation_volume_list
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: discussion about activation/auto_activation_volume_list
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: issue about return value in _lvchange_activate_single
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: discussion about activation/auto_activation_volume_list
- From: Gang He <ghe@xxxxxxxx>
- Re: discussion about activation/auto_activation_volume_list
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: issue about return value in _lvchange_activate_single
- From: David Teigland <teigland@xxxxxxxxxx>
- discussion about activation/auto_activation_volume_list
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- issue about return value in _lvchange_activate_single
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Identifying Unused VG
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Identifying Unused VG
- From: Annamalai Gurusami <annamalai.gurusami@xxxxxxxxxx>
- Re: [PATCH] man: document that 2 times poolmetadatasize is allocated for lvmthin
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- [PATCH] man: document that 2 times poolmetadatasize is allocated for lvmthin
- From: Scott Moser <ssmoser@xxxxxxxxx>
- [PATCH] man: document that 2 times poolmetadatasize is allocated for lvmthin
- From: Scott Moser <smoser@xxxxxxxxxxxx>
- Re: Why does thinpool take 2*poolmetadatasize space?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Why does thinpool take 2*poolmetadatasize space?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Why does thinpool take 2*poolmetadatasize space?
- From: Scott Moser <smoser@xxxxxxxxxxxx>
- Re: Identifying Unused VG
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Identifying Unused VG
- From: Annamalai Gurusami <annamalai.gurusami@xxxxxxxxxx>
- Re: Identifying Unused VG
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Suggestion: lvm2 filters lib needs to show some readable info for end user
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Suggestion: lvm2 filters lib needs to show some readable info for end user
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: Suggestion: lvm2 filters lib needs to show some readable info for end user
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Identifying Unused VG
- From: Annamalai Gurusami <annamalai.gurusami@xxxxxxxxxx>
- Re: LVM PV UUID problem
- From: Marian Csontos <mcsontos@xxxxxxxxxx>
- Re: raid0 - no performance increase??
- From: Bastian Blank <bblank@xxxxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxxxxxx>
- raid0 - no performance increase??
- From: lejeczek <peljasz@xxxxxxxxxxx>
- Re: LVM PV UUID problem
- From: "Mark H. Wood" <mwood@xxxxxxxxx>
- Re: LVM PV UUID problem
- From: Digimer <lists@xxxxxxxxxx>
- Re: LVM PV UUID problem
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- LVM PV UUID problem
- From: Digimer <lists@xxxxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: lvresize cannot refresh LV size on on other hosts when extending LV with a shared lock
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: lvresize cannot refresh LV size on on other hosts when extending LV with a shared lock
- From: Gang He <ghe@xxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: thin: pool target too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvresize cannot refresh LV size on on other hosts when extending LV with a shared lock
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: lvresize cannot refresh LV size on on other hosts when extending LV with a shared lock
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- lvresize cannot refresh LV size on on other hosts when extending LV with a shared lock
- From: Gang He <GHe@xxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: thin: pool target too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: thin: pool target too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: thin: pool target too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: nl6720 <nl6720@xxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: nl6720 <nl6720@xxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: nl6720 <nl6720@xxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: Mark Mielke <mark.mielke@xxxxxxxxx>
- Re: thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: Why isn't issue_discards enabled by default?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Why isn't issue_discards enabled by default?
- From: nl6720 <nl6720@xxxxxxxxx>
- Re: Removing lvmcache fails
- From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
- Re: Removing lvmcache fails
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Removing lvmcache fails
- From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
- Re: Removing lvmcache fails
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: thin: pool target too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Removing lvmcache fails
- From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
- thin: pool target too small
- From: Duncan Townsend <duncancmt@xxxxxxxxx>
- Re: [PATCH v2] lvs: add -o lv_usable
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [PATCH v2] lvs: add -o lv_usable
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: size of lvm metadata
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: size of lvm metadata
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: [PATCH v2] lvs: add -o lv_usable
- From: "heming.zhao" <heming.zhao@xxxxxxxx>
- Re: lvmcache with vdo - inconsistent block size
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvmcache with vdo - inconsistent block size
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvmcache with vdo - inconsistent block size
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: [PATCH v2] lvs: add -o lv_usable
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- size of lvm metadata
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- metadata size question
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: lvmcache with vdo - inconsistent block size
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: lvm limitations
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: lvm limitations
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: lvm limitations
- From: Stuart D Gathman <stuart@xxxxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvmcache with vdo - inconsistent block size
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: vgcfgrestore + pvcreate using liblockdev api in C
- From: Vojtěch Trefný <vtrefny@xxxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- lvmcache with vdo - inconsistent block size
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- vgcfgrestore + pvcreate using liblockdev api in C
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: [PATCH 1/2] metadata: check pv->dev null when setting PARTIAL_LV
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH 1/2] metadata: check pv->dev null when setting PARTIAL_LV
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [PATCH 1/2] metadata: check pv->dev null when setting PARTIAL_LV
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- [PATCH 2/2] [.gitignore]: ignore all cscope generated files
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- [PATCH 1/2] metadata: check pv->dev null when setting PARTIAL_LV
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: exposing snapshot block device
- From: Dalebjörk, Tomas <tomas.dalebjork@xxxxxxxxx>
- Re: [PATCH v2] lvs: add -o lv_usable
- From: "heming.zhao" <heming.zhao@xxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: [PATCH v2] lvs: add -o lv_usable
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- [PATCH v2] lvs: add -o lv_usable
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
- Re: [PATCH] lvs: add -o lv_usable
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: [PATCH] lvs: add -o lv_usable
- From: "heming.zhao" <heming.zhao@xxxxxxxx>
- Re: exposing snapshot block device
- From: Dalebjörk, Tomas <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: [PATCH] lvs: add -o lv_usable
- From: Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: exposing snapshot block device
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH] lvs: add -o lv_usable
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Looking ahead - tiering with LVM?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: pvcreate to memory
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: pvcreate to memory
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: [PATCH] lvs: add -o lv_usable
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] lvs: add -o lv_usable
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: pvcreate to memory
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- pvcreate to memory
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] gcc: change zero-sized array to fexlible array
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Looking ahead - tiering with LVM?
- From: Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx>
- Re: [PATCH] gcc: change zero-sized array to fexlible array
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: lvm limitations
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: "heming.zhao" <heming.zhao@xxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvm limitations
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: lvm limitations
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- lvm limitations
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: [PATCH] gcc: change zero-sized array to fexlible array
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [PATCH] gcc: change zero-sized array to fexlible array
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH v2] lib/metadata: add new api lv_is_available()
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH v2] lib/metadata: add new api lv_is_available()
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: [PATCH] lib/metadata: add new api lv_is_available()
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] lib/metadata: add new api lv_is_available()
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: [PATCH] lvdisplay: dispaly correct status on linear type
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Regarding the configure error while updating the LVM2 package
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- Re: [PATCH] lvdisplay: dispaly correct status on linear type
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: [PATCH] lvdisplay: dispaly correct status on linear type
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] lvdisplay: dispaly correct status on linear type
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: Regarding the configure error while updating the LVM2 package
- From: Bastian Blank <bblank@xxxxxxxxxx>
- Re: [PATCH] gcc: change zero-sized array to fexlible array
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Regarding the configure error while updating the LVM2 package
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- Re: Regarding the configure error while updating the LVM2 package
- From: KrishnaMurali Chennuboina <krishchennu414@xxxxxxxxx>
- Re: What to do about new lvm messages
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: What to do about new lvm messages
- From: L A Walsh <law@xxxxxxxxx>
- Re: What to do about new lvm messages
- From: Stuart D Gathman <stuart@xxxxxxxxxxx>
- What to do about new lvm messages
- From: L A Walsh <lvm@xxxxxxxxx>
- [PATCH v3] lvdisplay: dispaly correct status when underlying devs missing
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- [PATCH v2] lvdisplay: dispaly partial when underlying devs missing
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: [PATCH] gcc: change zero-sized array to fexlible array
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] gcc: change zero-sized array to fexlible array
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: [PATCH] lvdisplay: dispaly partial when underlying devs missing
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] lvdisplay: dispaly partial when underlying devs missing
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: extend raid5 - how if possible?
- From: Christopher Jacoby <cjacoby75@xxxxxxxxx>
- Re: extend raid5 - how if possible?
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- extend raid5 - how if possible?
- From: lejeczek <peljasz@xxxxxxxxxxx>
- Re: [PATCH] tests: use correct RA size, underly dev & delay time.
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: [PATCH] tests: use correct RA size, underly dev & delay time.
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- [PATCH] tests: use correct RA size, underly dev & delay time.
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: how often does lvm team update source code in ftp site
- From: "Frank Ch. Eigler" <fche@xxxxxxxxxxx>
- Re: how often does lvm team update source code in ftp site
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: what will happen with lvconvert merge after reboot?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: how often does lvm team update source code in ftp site
- From: Marian Csontos <mcsontos@xxxxxxxxxx>
- how often does lvm team update source code in ftp site
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- what will happen with lvconvert merge after reboot?
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: RAID-less parity?
- From: Janne Heß <janne+lvm@xxxxxxxx>
- Re: What do these messages mean?
- From: David Teigland <teigland@xxxxxxxxxx>
- What do these messages mean?
- From: Orion Poplawski <orion@xxxxxxxx>
- Re: lvm question regarding start and placement of data
- From: L A Walsh <lvm@xxxxxxxxx>
- Re: lvm question regarding start and placement of data
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: lvm question regarding start and placement of data
- From: L A Walsh <lvm@xxxxxxxxx>
- Re: lvm question regarding start and placement of data
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- lvm question regarding start and placement of data
- From: L A Walsh <lvm@xxxxxxxxx>
- Re: Suggestion: lvm2 filters lib needs to show some readable info for end user
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Suggestion: lvm2 filters lib needs to show some readable info for end user
- From: David Teigland <teigland@xxxxxxxxxx>
- Suggestion: lvm2 filters lib needs to show some readable info for end user
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: Failed to update old PV extension headers in VG
- From: Henk Kraal <h.kraal@xxxxxxxxx>
- Re: Failed to update old PV extension headers in VG
- From: David Teigland <teigland@xxxxxxxxxx>
- Failed to update old PV extension headers in VG
- From: Henk Kraal <h.kraal@xxxxxxxxx>
- Re: RAID-less parity?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: RAID-less parity?
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: RAID-less parity?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: [dm-crypt] LuksOpen hangs ?
- From: B&A Consultants <infos+dmcrypt@xxxxxxxxxxxxxxxxx>
- issue: lvm auto activate rmeta/rimage instead of the LV on these raid LVs
- From: Zhai Zhaoxuan <kxuanobj@xxxxxxxxx>
- RAID-less parity?
- From: Janne Heß <janne+lvm@xxxxxxxx>
- in lvm Shell --reportformat json is ignored
- From: Oliver Rath <rath@xxxxxxxx>
- Re: About online pvmove/lvresize on shared VG
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: About online pvmove/lvresize on shared VG
- From: Gang He <ghe@xxxxxxxx>
- Re: About online pvmove/lvresize on shared VG
- From: David Teigland <teigland@xxxxxxxxxx>
- About online pvmove/lvresize on shared VG
- From: Gang He <GHe@xxxxxxxx>
- Re: Difference between thin_ll_xxx & thin_xxx
- From: lampahome <pahome.chen@xxxxxxxxxx>
- Re: Difference between thin_ll_xxx & thin_xxx
- From: Ming-Hung Tsai <mingnus@xxxxxxxxx>
- Difference between thin_ll_xxx & thin_xxx
- From: lampahome <pahome.chen@xxxxxxxxxx>
- Feature request: support for editline
- From: Bastian Germann <bastiangermann@xxxxxxxxxxx>
- Re: [dm-crypt] LuksOpen hangs ?
- From: Ondrej Kozina <okozina@xxxxxxxxxx>
- Re: Removing VG mappings using dmsetup tool
- From: Vojtech Juranek <vjuranek@xxxxxxxxxx>
- Re: Removing VG mappings using dmsetup tool
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Removing VG mappings using dmsetup tool
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Removing VG mappings using dmsetup tool
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Removing VG mappings using dmsetup tool
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Removing VG mappings using dmsetup tool
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Removing VG mappings using dmsetup tool
- From: Vojtech Juranek <vjuranek@xxxxxxxxxx>
- [PATCH] Change dev->bcache_fd default value from 0 to -1
- From: Zhao Heming <heming.zhao@xxxxxxxx>
- Re: How to repair superblock is corrupt
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- How to repair superblock is corrupt
- From: lampahome <pahome.chen@xxxxxxxxxx>
- question about vg underlying pv devs order
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: issue (or bug): when vgremove does removing lvmcache
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: issue (or bug): when vgremove does removing lvmcache
- From: David Teigland <teigland@xxxxxxxxxx>
- issue (or bug): when vgremove does removing lvmcache
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: [lvmlockd] sanlock stuck while getting VGLK
- From: Damon Wang <damon.devops@xxxxxxxxx>
- Re: [lvmlockd] sanlock stuck while getting VGLK
- From: David Teigland <teigland@xxxxxxxxxx>
- [lvmlockd] sanlock stuck while getting VGLK
- From: Damon Wang <damon.devops@xxxxxxxxx>
- Re: can we change cluster_ringid_seq in libdlm from uint32_t to uint64_t?
- From: Gang He <GHe@xxxxxxxx>
- Re: [general question] rare silent data corruption when writing data
- From: Michal Soltys <msoltyspl@xxxxxxxxx>
- Re: [general question] rare silent data corruption when writing data
- From: "John Stoffel" <john@xxxxxxxxxxx>
- lvmcache comes back dirty after unclean shutdown
- From: Paul Richards <paul.richards@xxxxxxxxx>
- Re: can we change cluster_ringid_seq in libdlm from uint32_t to uint64_t?
- From: David Teigland <teigland@xxxxxxxxxx>
- can we change cluster_ringid_seq in libdlm from uint32_t to uint64_t?
- From: Gang He <GHe@xxxxxxxx>
- Re: udev/10-dm.rules.in: unexpectedly skipping device?
- From: Michael Stapelberg <michael+lvm@xxxxxxxxxxxxx>
- Re: udev/10-dm.rules.in: unexpectedly skipping device?
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- udev/10-dm.rules.in: unexpectedly skipping device?
- From: Michael Stapelberg <michael+lvm@xxxxxxxxxxxxx>
- Re: [1019133-4yqc8ex4] LVM hangs after volume change
- From: Stuart D Gathman <stuart@xxxxxxxxxxx>
- [1019133-4yqc8ex4] LVM hangs after volume change
- From: "Shock Media B.V. support" <support@xxxxxxxxxxxxx>
- Re: lvcreate: adding devices causes an alignment inconsistencies
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: lvm raid5 : drives all present but vg/lvm will not assemble
- From: Andrew Falgout <digitalw00t@xxxxxxxxx>
- lvcreate: adding devices causes an alignment inconsistencies
- From: Bernhard Sulzer <micraft.b@xxxxxxxxx>
- Re: storage-logger: Recording changes to the udev database
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- Re: storage-logger: Recording changes to the udev database
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: storage-logger: Recording changes to the udev database
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- Re: storage-logger: Recording changes to the udev database
- From: Brian McCullough <bdmc@xxxxxxxxxxxx>
- storage-logger: Recording changes to the udev database
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: lvm raid5 : drives all present but vg/lvm will not assemble
- From: Andrew Falgout <digitalw00t@xxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Q: lvcreate, systemd and tmp.mount
- From: pasxizeis <pasxizeis@xxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Scott Mcdermott <scott@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Scott Mcdermott <scott@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: lvm raid5 : drives all present but vg/lvm will not assemble
- From: Roger Heflin <rogerheflin@xxxxxxxxx>
- Re: lvm raid5 : drives all present but vg/lvm will not assemble
- From: Bernd Eckenfels <ecki@xxxxxxxxxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: when bringing dm-cache online, consumes all memory and reboots
- From: Joe Thornber <thornber@xxxxxxxxxx>
- lvm raid5 : drives all present but vg/lvm will not assemble
- From: Andrew Falgout <digitalw00t@xxxxxxxxx>
- when bringing dm-cache online, consumes all memory and reboots
- From: Scott Mcdermott <scott@xxxxxxxxxx>
- Re: probable lvm thin_pool exhaustion
- From: Marian Csontos <mcsontos@xxxxxxxxxx>
- Re: probable lvm thin_pool exhaustion
- From: Ming-Hung Tsai <mingnus@xxxxxxxxx>
- Re: Do we have a way to clone the customer lvm2 environment?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- probable lvm thin_pool exhaustion
- Do we have a way to clone the customer lvm2 environment?
- From: Gang He <GHe@xxxxxxxx>
- probable lvm thin_pool exhaustion
- Re: lvm+ sanlock snapshot issue
- From: David Teigland <teigland@xxxxxxxxxx>
- lvm+ sanlock snapshot issue
- From: Andrea Leofreddi <a.leofreddi@xxxxxxxx>
- stable-2.02 missing patch files for lib/device/bcache.c
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: faster snapshot creation?
- From: Douglas Paul <doug@xxxxxxxx>
- Re: faster snapshot creation?
- From: Eric Toombs <ewtoombs@xxxxxxxxxxxx>
- Re: faster snapshot creation?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: faster snapshot creation?
- From: "Stuart D. Gathman" <stuart@xxxxxxxxxxx>
- Re: faster snapshot creation?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: faster snapshot creation?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- faster snapshot creation?
- From: Eric Toombs <ewtoombs@xxxxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: commit c527a0cbfc3 may have a bug
- From: David Teigland <teigland@xxxxxxxxxx>
- commit c527a0cbfc3 may have a bug
- From: "heming.zhao@xxxxxxxx" <heming.zhao@xxxxxxxx>
- Re: pvmove --abort
- From: Matthias Leopold <matthias.leopold@xxxxxxxxxxxxxxxx>
- Re: pvmove --abort
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: pvmove --abort
- From: Stuart D Gathman <stuart@xxxxxxxxxxx>
- pvmove --abort
- From: Matthias Leopold <matthias.leopold@xxxxxxxxxxxxxxxx>
- [PATCH 2/2] Update man page to include --reportformat for list and report subcommands
- From: Todd Gill <tgill@xxxxxxxxxx>
- [PATCH 1/2] Add JSON output support to dmstats for list and report subcommands
- From: Todd Gill <tgill@xxxxxxxxxx>
- [PATCH 0/2] JSON output for dmstats
- From: Todd Gill <tgill@xxxxxxxxxx>
- Re: Deeply impressed
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Deeply impressed
- From: Michael Lipp <mnl@xxxxxx>
- Re: Failed merge, still running?
- From: Mauricio Tavares <raubvogel@xxxxxxxxx>
- Re: Failed merge, still running?
- From: "Stuart D. Gathman" <stuart@xxxxxxxxxxx>
- Re: Failed merge, still running?
- From: Mauricio Tavares <raubvogel@xxxxxxxxx>
- Re: Failed merge, still running?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Failed merge, still running?
- From: Mauricio Tavares <raubvogel@xxxxxxxxx>
- Re: Time needed for take a snapshot
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Time needed for take a snapshot
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Time needed for take a snapshot
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Time needed for take a snapshot
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Time needed for take a snapshot
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- [PATCH] [vgreduce] add suggestion message for mirror LVs
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- [PATCH] [test] fix corosync.conf: no interface error
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: lvreduce thin-pool
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- lvreduce thin-pool
- From: Paul Dann <pdgiddie@xxxxxxxxx>
- Re: lvmcache on non-lvm source?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: lvmcache on non-lvm source?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- lvmcache on non-lvm source?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: metadata device too small
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- Re: metadata device too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: metadata device too small
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- Re: metadata device too small
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: metadata device too small
- From: Marian Csontos <mcsontos@xxxxxxxxxx>
- Re: metadata device too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: metadata device too small
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: metadata device too small
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: metadata device too small
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- Re: metadata device too small
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- metadata device too small
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- Re: thinpool metadata got way too large, how to handle?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: thinpool metadata got way too large, how to handle?
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- Re: thinpool metadata got way too large, how to handle?
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- Re: thinpool metadata got way too large, how to handle?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- [PATCH 1/1] build: force to use bash (was: Re: bashism in tools/Makefile.in)
- From: Christian Hesse <list@xxxxxxxx>
- Re: bashism in tools/Makefile.in
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- bashism in tools/Makefile.in
- From: Christian Hesse <list@xxxxxxxx>
- Re: Question about vgreduce on raid lvm cache
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- thinpool metadata got way too large, how to handle?
- From: Ede Wolf <listac@xxxxxxxxxxxxxxxx>
- [PATCH] generator: fix file descriptor leak
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Best way to run LVM over multiple SW RAIDs?
- From: Daniel Janzon <daniel.janzon@xxxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Łukasz Czerpak <lukasz.czerpak@xxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Łukasz Czerpak <lukasz.czerpak@xxxxxxxxx>
- Re: linux-lvm Digest, Vol 190, Issue 6
- From: Daniel Janzon <daniel.janzon@xxxxxxxxxxx>
- Re: It looks wrong for the timeout when lvm test running
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: It looks wrong for the timeout when lvm test running
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: It looks wrong for the timeout when lvm test running
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Marian Csontos <mcsontos@xxxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Łukasz Czerpak <lukasz.czerpak@xxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Łukasz Czerpak <lukasz.czerpak@xxxxxxxxx>
- Re: Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Łukasz Czerpak <lukasz.czerpak@xxxxxxxxx>
- Re: It looks wrong for the timeout when lvm test running
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: It looks wrong for the timeout when lvm test running
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Guoqing Jiang <guoqing.jiang@xxxxxxxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Daniel Janzon <daniel.janzon@xxxxxxxxxxx>
- Re: It looks wrong for the timeout when lvm test running
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- It looks wrong for the timeout when lvm test running
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
- From: Łukasz Czerpak <lukasz.czerpak@xxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: "Stuart D. Gathman" <stuart@xxxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: "John Stoffel" <john@xxxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: "Stuart D. Gathman" <stuart@xxxxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Roberto Fastec <roberto.fastec@xxxxxxxxx>
- Re: Best way to run LVM over multiple SW RAIDs?
- From: Anatoly Pugachev <matorola@xxxxxxxxx>
- Question about vgreduce on raid lvm cache
- From: Heming Zhao <heming.zhao@xxxxxxxx>
- Re: resend patch - bcache may mistakenly write data to another disk when writes error
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: resend patch - bcache may mistakenly write data to another disk when writes error
- From: David Teigland <teigland@xxxxxxxxxx>
- Re: exposing snapshot block device
- From: Tomas Dalebjörk <tomas.dalebjork@xxxxxxxxx>
- Re: exposing snapshot block device
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: exposing snapshot block device
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
[Index of Archives]
[Gluster Users]
[Ceph Users]
[Filesystem Development]
[Kernel Development]
[Security]
[Bugtraq]
[Linux Clusters]
