Hi Mikulas,
> bio_alloc can allocate a bio with at most BIO_MAX_PAGES (256) vector
> entries. However, the incoming bio may have more vector entries if it was
> allocated by other means. For example, bcache submits bios with more than
> BIO_MAX_PAGES entries. This results in bio_alloc failure.
>
ap
> and dm_accept_partial_bio to split the bio. dm_accept_partial_bio trims
> the current bio to the desired size and requests that the device mapper
> core sends another bio with the rest of the data.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org# v3.16+
> On Fri, 20 May 2016, James Johnston wrote:
>
> > > On Mon, 16 May 2016, Tim Small wrote:
> > >
> > > > On 08/05/16 19:39, James Johnston wrote:
> > > > > I've run into a problem where the bcache writeback cache can't be
> > >
> On Mon, 16 May 2016, Tim Small wrote:
>
> > On 08/05/16 19:39, James Johnston wrote:
> > > I've run into a problem where the bcache writeback cache can't be flushed
> > > to
> > > disk when the backing device is a LUKS / dm-crypt device and th
> On Sun, 8 May 2016, James Johnston wrote:
>
> > Hi,
> >
> > [1.] One line summary of the problem:
> >
> > bcache gets stuck flushing writeback cache when used in combination with
> > LUKS/dm-crypt and non-default bucket size
> >
> > [2.] Fu
l: 00 Id: 00 Lun: 00
Vendor: ATA Model: VMware Virtual S Rev: 0001
Type: Direct-Access ANSI SCSI revision: 05
Best regards,
James Johnston
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
