On 1/24/21 3:02 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series switches back from storing the gendisk + partno to storing
> a block_device pointer in struct bio. The reason is two fold: for one
> the new struct block_device actually is always available, removing the
> need to avoid
Hi Jens,
this series switches back from storing the gendisk + partno to storing
a block_device pointer in struct bio. The reason is two fold: for one
the new struct block_device actually is always available, removing the
need to avoid originally. Second the merge struct block_device is much
On Tue, 2020-12-08 at 12:04 +0100, Christoph Hellwig wrote:
> can you send me details of your device mapper setup, e.g. which targets
> are used, are they used on top of whole device or partitions. Do you
> use partitions on top of the dm devices? Are any other stacking devices
> involved?
It
On Tue, 2020-12-01 at 17:54 +0100, Christoph Hellwig wrote:
> Hi Jens,
>
> this series switches back from storing the gendisk + partno to storing
> a block_device pointer in struct bio. The reason is two fold: for one
> the new struct block_device actually is always available, removing the
>
On 12/8/20 4:04 AM, Christoph Hellwig wrote:
> Hi Qian,
>
> can you send me details of your device mapper setup, e.g. which targets
> are used, are they used on top of whole device or partitions. Do you
> use partitions on top of the dm devices? Are any other stacking devices
> involved?
Don't
On Tue, Dec 08, 2020 at 12:04:03PM +0100, Christoph Hellwig wrote:
> can you send me details of your device mapper setup, e.g. which targets
> are used, are they used on top of whole device or partitions. Do you
> use partitions on top of the dm devices? Are any other stacking devices
>
Hi Qian,
can you send me details of your device mapper setup, e.g. which targets
are used, are they used on top of whole device or partitions. Do you
use partitions on top of the dm devices? Are any other stacking devices
involved?
On Mon, Dec 07, 2020 at 01:56:26PM -0500, Qian Cai wrote:
> On
On 12/7/20 12:01 PM, Christoph Hellwig wrote:
> Thanks for the report.
>
> Jens, can you revert the series for now? I think waiting any longer
> with a report like this is not helpful. I'll look into it with
> Qian in the meantime.
Agree, I reverted it.
--
Jens Axboe
--
dm-devel mailing
Thanks for the report.
Jens, can you revert the series for now? I think waiting any longer
with a report like this is not helpful. I'll look into it with
Qian in the meantime.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On 12/1/20 9:54 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series switches back from storing the gendisk + partno to storing
> a block_device pointer in struct bio. The reason is two fold: for one
> the new struct block_device actually is always available, removing the
> need to avoid
On Wed, Dec 02, 2020 at 05:35:21PM -0500, Tejun Heo wrote:
> On Tue, Dec 01, 2020 at 05:54:15PM +0100, Christoph Hellwig wrote:
> > Hi Jens,
> >
> > this series switches back from storing the gendisk + partno to storing
> > a block_device pointer in struct bio. The reason is two fold: for one
>
On Tue, Dec 01, 2020 at 05:54:15PM +0100, Christoph Hellwig wrote:
> Hi Jens,
>
> this series switches back from storing the gendisk + partno to storing
> a block_device pointer in struct bio. The reason is two fold: for one
> the new struct block_device actually is always available, removing
Hi Jens,
this series switches back from storing the gendisk + partno to storing
a block_device pointer in struct bio. The reason is two fold: for one
the new struct block_device actually is always available, removing the
need to avoid originally. Second the merge struct block_device is much
13 matches
Mail list logo
