Hi,
with todays git I got a huge amount of warnings for device mapper:
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: [email protected]
device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
device-mapper: table: 252:0: target device dasde1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
device-mapper: table: 252:0: target device dasde1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
device-mapper: table: 252:1: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=5368905728
device-mapper: table: 252:1: target device dasde1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=5368905728
device-mapper: table: 252:1: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=5368905728
device-mapper: table: 252:1: target device dasde1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=5368905728
device-mapper: table: 252:2: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=6979518464
device-mapper: table: 252:2: target device dasde1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=6979518464
device-mapper: table: 252:2: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=6979518464
device-mapper: table: 252:2: target device dasde1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=6979518464
device-mapper: table: 252:3: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=7189233664
[...]
But the system seems to work fine.
The same devices produce no warning with a 2.6.32 vanilla kernel.
[root@t63lp34 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/dasdf1
VG Name space
PV Size 22.49 GB / not usable 2.28 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 5758
Free PE 3
Allocated PE 5755
PV UUID Uocvlz-I6wv-JtLH-8W5L-ziib-pP7h-4Qdzgz
--- Physical volume ---
PV Name /dev/dasde1
VG Name space
PV Size 22.49 GB / not usable 2.28 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 5758
Free PE 15
Allocated PE 5743
PV UUID UuM16H-GUdC-gfA3-3yvE-c5Af-UVPW-Cfe2no
--- Physical volume ---
PV Name /dev/dasdd1
VG Name space
PV Size 4.59 GB / not usable 3.38 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 1173
Free PE 0
Allocated PE 1173
PV UUID 800CzR-0hjD-lL6Z-yQPt-vRcl-WlYp-cUtZwJ
--- Physical volume ---
PV Name /dev/dasdc1
VG Name space
PV Size 4.59 GB / not usable 3.38 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 1173
Free PE 12
Allocated PE 1161
PV UUID hG8bJE-xYJL-eo0N-tsD5-kdcH-AONB-FGdtAK
[root@t63lp34 ~]# vgdisplay
--- Volume group ---
VG Name space
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 96
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 65
Open LV 4
Max PV 0
Cur PV 4
Act PV 4
VG Size 54.15 GB
PE Size 4.00 MB
Total PE 13862
Alloc PE / Size 13832 / 54.03 GB
Free PE / Size 30 / 120.00 MB
VG UUID AcRPg8-6DaJ-ND6i-s3H7-Sh5V-8KWa-KtKRmv
On 09.12.2009, Christian Borntraeger wrote:
> with todays git I got a huge amount of warnings for device mapper:
> device-mapper: uevent: version 1.0.3
> device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: [email protected]
> device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
[...]
> The same devices produce no warning with a 2.6.32 vanilla kernel.
I have exactly the same here...
On Wed, Dec 09 2009, Heinz Diehl wrote:
> On 09.12.2009, Christian Borntraeger wrote:
>
> > with todays git I got a huge amount of warnings for device mapper:
> > device-mapper: uevent: version 1.0.3
> > device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: [email protected]
> > device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
> [...]
>
> > The same devices produce no warning with a 2.6.32 vanilla kernel.
>
> I have exactly the same here...
Can either one of you try and bisect it? I've cc'ed Martin, it's likely
one of the io stacking patches that causes this.
--
Jens Axboe
On Wed, Dec 09 2009, Jens Axboe wrote:
> On Wed, Dec 09 2009, Heinz Diehl wrote:
> > On 09.12.2009, Christian Borntraeger wrote:
> >
> > > with todays git I got a huge amount of warnings for device mapper:
> > > device-mapper: uevent: version 1.0.3
> > > device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: [email protected]
> > > device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
> > [...]
> >
> > > The same devices produce no warning with a 2.6.32 vanilla kernel.
> >
> > I have exactly the same here...
>
> Can either one of you try and bisect it? I've cc'ed Martin, it's likely
> one of the io stacking patches that causes this.
Does this work?
diff --git a/block/blk-settings.c b/block/blk-settings.c
index dd1f1e0..0116d29 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -554,11 +554,13 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
ret = -1;
}
+#if 0
if (offset &&
(offset & (b->discard_granularity - 1)) != b->discard_alignment) {
t->discard_misaligned = 1;
ret = -1;
}
+#endif
/* If top has no alignment offset, inherit from bottom */
if (!t->alignment_offset)
--
Jens Axboe
On Wed, Dec 9, 2009 at 5:07 PM, Jens Axboe <[email protected]> wrote:
> On Wed, Dec 09 2009, Jens Axboe wrote:
>> On Wed, Dec 09 2009, Heinz Diehl wrote:
>> > On 09.12.2009, Christian Borntraeger wrote:
>> >
>> > > with todays git I got a huge amount of warnings for device mapper:
>> > > device-mapper: uevent: version 1.0.3
>> > > device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: [email protected]
>> > > device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
>> > [...]
>> >
>> > > The same devices produce no warning with a 2.6.32 vanilla kernel.
>> >
>> > I have exactly the same here...
>>
>> Can either one of you try and bisect it? I've cc'ed Martin, it's likely
>> one of the io stacking patches that causes this.
>
> Does this work?
>
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index dd1f1e0..0116d29 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -554,11 +554,13 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
> ? ? ? ? ? ? ? ?ret = -1;
> ? ? ? ?}
>
> +#if 0
> ? ? ? ?if (offset &&
> ? ? ? ? ? ?(offset & (b->discard_granularity - 1)) != b->discard_alignment) {
> ? ? ? ? ? ? ? ?t->discard_misaligned = 1;
> ? ? ? ? ? ? ? ?ret = -1;
> ? ? ? ?}
> +#endif
>
> ? ? ? ?/* If top has no alignment offset, inherit from bottom */
> ? ? ? ?if (!t->alignment_offset)
Jens,
It should be noted that Christian (original poster but cc's got
dropped) is using striped LVs.
Striped LVs use blk_limits_io_opt() via drivers/md/dm-stripe.c:stripe_io_hints()
Martin's change for discard alignment (commit: 86b37281) also splits
out the least common multiple code, that was exclusively used for
io_opt, to a new lcm() function in block/blk-settings.c
On the surface I thought this might be the reason for the warnings,
but Martin's lcm() looks perfectly fine; can't see why it would cause
these warnings to appear all of a sudden... but I figured I'd share.
It'll be interesting to see if the discard_granularity block you
#ifdef'd out helps either Christian or Heinz.
Mike
>>>>> "Mike" == Mike Snitzer <[email protected]> writes:
Mike> On the surface I thought this might be the reason for the
Mike> warnings, but Martin's lcm() looks perfectly fine; can't see why
Mike> it would cause these warnings to appear all of a sudden... but I
Mike> figured I'd share.
The warning is caused by an error in stacking discard granularity. I
have a fix but I'd like to run verify all my oddball alignment combos
before submitting.
--
Martin K. Petersen Oracle Linux Engineering
Am Mittwoch 09 Dezember 2009 23:07:49 schrieb Jens Axboe:
> > > > device-mapper: table: 252:0: target device dasdf1 is misaligned: physical_block_size=4096, logical_block_size=4096, alignment_offset=0, start=196608
[...]
> Does this work?
[...]
> +#if 0
> if (offset &&
> (offset & (b->discard_granularity - 1)) != b->discard_alignment) {
> t->discard_misaligned = 1;
> ret = -1;
> }
> +#endif
Yes it does.
On 10.12.2009, Christian Borntraeger wrote:
> Yes it does.
Yes, that fixes it for me too.
Thanks,
Heinz.
Am Donnerstag 10 Dezember 2009 02:14:03 schrieb Martin K. Petersen:
> The warning is caused by an error in stacking discard granularity. I
> have a fix but I'd like to run verify all my oddball alignment combos
> before submitting.
Martin,
any news on the final fix? Do you want Heinz and me to verify your fix
on our systems?
Christian
>>>>> "Christian" == Christian Borntraeger <[email protected]> writes:
Christian> any news on the final fix? Do you want Heinz and me to verify
Christian> your fix on our systems?
Looking into this issue unearthed an unrelated problem with the topology
stacking algorithm that turns out to be much trickier to fix. That's
what's taking time.
Since the first bug is simply causing a warning I'm inclined to get
everything fixed up before having Jens queue a fix. Shouldn't be more
than a day or two before I have all this worked out.
--
Martin K. Petersen Oracle Linux Engineering
On Wed, 9 Dec 2009 at 23:07, Jens Axboe wrote:
> Does this work?
Although not using LVM, these messages were popping up here too. Your
patch made these go away with no ill effects so far.
Dmesg and .config: http://nerdbynature.de/bits/2.6.33-git/dm/
Thanks,
Christian.
>
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index dd1f1e0..0116d29 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -554,11 +554,13 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
> ret = -1;
> }
>
> +#if 0
> if (offset &&
> (offset & (b->discard_granularity - 1)) != b->discard_alignment) {
> t->discard_misaligned = 1;
> ret = -1;
> }
> +#endif
>
> /* If top has no alignment offset, inherit from bottom */
> if (!t->alignment_offset)
--
BOFH excuse #254:
Interference from lunar radiation
On Wed, 9 Dec 2009 at 23:07, Jens Axboe wrote:
> Does this work?
>
[...]
> +#if 0
> if (offset &&
> (offset & (b->discard_granularity - 1)) != b->discard_alignment) {
> t->discard_misaligned = 1;
> ret = -1;
> }
> +#endif
I can't tell: is this a purely cosmetical change or is it dangerous to run
my DM devices without that patch? I'm trying to track mainline -git but
the patch hasn't made into the tree yet, so I always have to manually
apply the patch - or can I just ignore the warning?
Christian.
--
BOFH excuse #153:
Big to little endian conversion error
On Tue, Dec 15 2009, Christian Kujau wrote:
> On Wed, 9 Dec 2009 at 23:07, Jens Axboe wrote:
> > Does this work?
> >
> [...]
> > +#if 0
> > if (offset &&
> > (offset & (b->discard_granularity - 1)) != b->discard_alignment) {
> > t->discard_misaligned = 1;
> > ret = -1;
> > }
> > +#endif
>
> I can't tell: is this a purely cosmetical change or is it dangerous to run
> my DM devices without that patch? I'm trying to track mainline -git but
> the patch hasn't made into the tree yet, so I always have to manually
> apply the patch - or can I just ignore the warning?
You can ignore it, it wont harm the functionality or data integrity. The
code "failure" will always trigger, since the default settings are 0.
Thus:
(offset & (b->discard_granularity - 1)) != b->discard_alignment
will always be true.
I'll revert the bad commit tomorrow so that -rc1 wont be affected, at
least.
--
Jens Axboe
>>>>> "Jens" == Jens Axboe <[email protected]> writes:
Jens> I'll revert the bad commit tomorrow so that -rc1 wont be affected,
Jens> at least.
I'm pretty close to having a new stacking algorithm that works. If I
don't have it ready by tomorrow maybe we should commit the following
patch instead of reverting the discard changes wholesale?
diff --git a/block/blk-settings.c b/block/blk-settings.c
index dd1f1e0..65ae861 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -555,10 +555,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
}
if (offset &&
- (offset & (b->discard_granularity - 1)) != b->discard_alignment) {
+ (offset & (b->discard_granularity - 1)) != b->discard_alignment)
t->discard_misaligned = 1;
- ret = -1;
- }
/* If top has no alignment offset, inherit from bottom */
if (!t->alignment_offset)
On Tue, Dec 15 2009, Martin K. Petersen wrote:
> >>>>> "Jens" == Jens Axboe <[email protected]> writes:
>
> Jens> I'll revert the bad commit tomorrow so that -rc1 wont be affected,
> Jens> at least.
>
> I'm pretty close to having a new stacking algorithm that works. If I
> don't have it ready by tomorrow maybe we should commit the following
> patch instead of reverting the discard changes wholesale?
>
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index dd1f1e0..65ae861 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -555,10 +555,8 @@ int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
> }
>
> if (offset &&
> - (offset & (b->discard_granularity - 1)) != b->discard_alignment) {
> + (offset & (b->discard_granularity - 1)) != b->discard_alignment)
> t->discard_misaligned = 1;
> - ret = -1;
> - }
>
> /* If top has no alignment offset, inherit from bottom */
> if (!t->alignment_offset)
I guess we could do that, as long as it gets really fixed before 2.6.33.
It's a bit ugly to be exporting the device as misaligned, when it's
really just a fudged internally.
--
Jens Axboe