linux-kernel - Re: [dm-devel] bio too big device md1 (16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <876482ezuq.874pnmezuq@873b36ezuq.message.id>
Date:	Thu, 12 Apr 2007 11:13:48 +0200
From:	syrius.ml@...log.org
To:	Neil Brown <neilb@...e.de>
Cc:	linux-kernel@...r.kernel.org, Alasdair G Kergon <agk@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [dm-devel] bio too big device md1 (16 > 8)

Neil Brown <neilb@...e.de> writes:

> This is difficult.
>
> Summary of problem is:
>   Filesystem on LVM on md/raid1
>   Add an md/linear to the md/raid1 and fs dies with 'bio too big'.
>
> [...]
>
> You can probably make your array work by adding the md/linear array to
> the md/raid1 *before* enabling the LVM device on top of it.  However
> that isn't really a good long-term solution.

Thanks for the explanations !
That's the kind of solution i did use. But it seems I achieved to add
the md/linear array to the md/raid1 after lvm was enabled, I only have
to not to use an initrd.

the kernel I'm using at the moment is a 2.6.18-4-vserver-xen (debian
one) plus the following patches:
- dm-io-fix-bi_max_vecs.patch
- dm-merge-max_hw_sector.patch
also i'm using #define RESYNC_BLOCK_SIZE PAGE_SIZE rather than
(64*1024) in raid1.c.

Not sure if that could explain the fact i was able to add the md/linear
array to the md/raid1 after enabling lvm. (still i had not to use an
initrd)

When I have more time I'll try to reproduce this on a test machine.

> We really need better ways for stacked devices to communicate.
>
> Alasdair Kergon (dm developer) has some patches to make it practical
> to recursively call merge_bvec_fn so they might be part of the
> solution, but more discussion is needed before that becomes a reality.

Ok, i'd be curious to test them (if they're usable and publicly
available)

> Sorry I cannot be more helpful at this stage.

Thanks. (at least i understand(-ish) what's going on) ;-)

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/