On Mon, 7 Jan 2013 13:34:05 +0100 (CET) bug556610@arcor.de wrote: > > Hello, > thanks for responding. > > NeilBrown: > > The upstream bug tracker is > > mailto:linux-raid@vger.kernel.org > > Well ok, though a regular mailinglist makes it rather hard to get an overview for non-devs, > and reporting involves receiving unrelated messages. Reporting only requires that you send an email. You don't have to be subscribed to post - that would be a ridiculous requirement. :-) > > > This really needs to be fixed by cleaning up the bio path so that big bios > > are split by the device that needs the split, not be the fs sending the > > bio. > > Where ist that tracked? No sure exactly what you mean. However Kent Overstreet has been doing some work that could lead towards this: https://lkml.org/lkml/2012/10/15/398 NeilBrown > > > Maybe the best interim fix is to reject the added device is its limits are > > too low. > > Good Idea to avoid the data corruption. MD could save the > max_sectors default limit for arrays. If the array is modified and the new > limit gets smaller, postpone the sync until the next assembe/restart. > > And of course print a message if postponing, that explains when --force would be save. > What ever that would be: no block device abstraction layer (device mapper, lvm, luks,...) > between an unmounted? ext, fat?, ...? filesystem and md? > >
Attachment:
signature.asc
Description: PGP signature