Single-drive RAID0

am 08.02.2011 17:15:53 von krzysztof.wojcik

Neil,

I try to create a single-drive RAID0 array with data preservation.
It means I have a single disk with partitions and data on them.
I would like to migrate this single disk to RAID0 array and then grow it to N devices.
Of course I expect partitions with my useful data will be mapped to corresponding MD block devices (/dev/md126p1, /dev/md126p2 etc.). Indeed they are but when I try to mount new block device it disappears from /dev directory and mount is not succeeded.
/var/log/messages shows all the time:
md126: p1
md126: detected capacity change from 0 to xxxxxxxxxxxxx

It is not always reproducible but very often.
I try this operation on 0.9 and imsm metadata. Symptoms are similar.

Do you have any suggestions? How to fix this issue?

Regards
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 09.02.2011 03:45:57 von NeilBrown

On Tue, 8 Feb 2011 16:15:53 +0000 "Wojcik, Krzysztof"
wrote:

> Neil,
>
> I try to create a single-drive RAID0 array with data preservation.
> It means I have a single disk with partitions and data on them.
> I would like to migrate this single disk to RAID0 array and then grow it to N devices.
> Of course I expect partitions with my useful data will be mapped to corresponding MD block devices (/dev/md126p1, /dev/md126p2 etc.). Indeed they are but when I try to mount new block device it disappears from /dev directory and mount is not succeeded.
> /var/log/messages shows all the time:
> md126: p1
> md126: detected capacity change from 0 to xxxxxxxxxxxxx
>
> It is not always reproducible but very often.
> I try this operation on 0.9 and imsm metadata. Symptoms are similar.
>
> Do you have any suggestions? How to fix this issue?
>
> Regards
> Krzysztof

It isn't clear to me what the issue is and when I try something that might be
what you are suggesting it works perfectly every time.

Maybe if you could provide something more detailed and specific.
e.g. a series of steps that I can try together with all the messages you get
(both from the kernel and from mdadm) throughout the process.

That will probably help.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Single-drive RAID0

am 09.02.2011 15:33:01 von krzysztof.wojcik

--_002_BE2BFE91933D1B4089447C644860408068C4429Dirsmsx503gerc or_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steps to reproduce:
1. Create partition on disk (for example: 1 partition, size=3Dhalf of /dev/=
sda disk)
2. Create filesystem on partition (ext3)
3. Mount partition and create some control data on partition
4. Unmount partition
5. Create RAID0 on disk (mdadm -C /dev/md/vol_1 -amd -e 0.9 -c 64 -l 0 -n 1=
/dev/sda --force)
6. md127 and md127p1 appears in /dev as expected
7. Try to mount md127p1 and verify control data on them

Expected result:
md127p1 device mounted and control data not corrupted

Actual result:
1. Mount command returns error:
mount: special device /dev/md127p1 does not exists
2. md127p1 disappears from /dev/
3. kernel indefinitely shows (until array will be stop):
md126: p1
md126: detected capacity change from 0 to xxxxxxxxxxxxx
md126: p1
md126: detected capacity change from 0 to xxxxxxxxxxxxx
....

Additional Info:
Reproduced on:
- SLES11 SP1
- mdamd 3.2 from top of your devel-3.2 branch
- kernel 2.6.38 RC2

I've attached script that I use to reproduce this issue.
For native metadata run:
../raid_ready_drive native
For imsm metadata just:
../raid_ready_drive

Regards
Krzysztof

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Wednesday, February 09, 2011 3:46 AM
> To: Wojcik, Krzysztof
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Single-drive RAID0
>=20
> On Tue, 8 Feb 2011 16:15:53 +0000 "Wojcik, Krzysztof"
> wrote:
>=20
> > Neil,
> >
> > I try to create a single-drive RAID0 array with data preservation.
> > It means I have a single disk with partitions and data on them.
> > I would like to migrate this single disk to RAID0 array and then grow
> it to N devices.
> > Of course I expect partitions with my useful data will be mapped to
> corresponding MD block devices (/dev/md126p1, /dev/md126p2 etc.).
> Indeed they are but when I try to mount new block device it disappears
> from /dev directory and mount is not succeeded.
>=20
> > /var/log/messages shows all the time:
> > md126: p1
> > md126: detected capacity change from 0 to xxxxxxxxxxxxx
> >
> > It is not always reproducible but very often.
> > I try this operation on 0.9 and imsm metadata. Symptoms are similar.
> >
> > Do you have any suggestions? How to fix this issue?
> >
> > Regards
> > Krzysztof
>=20
> It isn't clear to me what the issue is and when I try something that
> might be
> what you are suggesting it works perfectly every time.
>=20
> Maybe if you could provide something more detailed and specific.
> e.g. a series of steps that I can try together with all the messages
> you get
> (both from the kernel and from mdadm) throughout the process.
>=20
> That will probably help.
>=20
> NeilBrown

--_002_BE2BFE91933D1B4089447C644860408068C4429Dirsmsx503gerc or_
Content-Type: application/octet-stream; name="raid_ready_drive"
Content-Description: raid_ready_drive
Content-Disposition: attachment; filename="raid_ready_drive"; size=2635;
creation-date="Wed, 09 Feb 2011 14:31:26 GMT";
modification-date="Wed, 09 Feb 2011 14:30:25 GMT"
Content-Transfer-Encoding: base64

IyEvYmluL2Jhc2gKClYxTU5UPS9tbnQvdm9sMQpWMk1OVD0vbW50L3ZvbDIK Q09OVD0vZGV2L21k
L2ltc20wCkZJTEVfU0laRT0xMDAwMDAwMDAKQ0hVTks9MTI4CgojIGRlZmlu ZSBkaXNrIGZvciB0
ZXN0cwojZGlzaz0vZGV2L3NkYQoKTjE9L2Rldi9tZC92b2xfMQoKZnVuY3Rp b24gc3RhdCgpIHsK
IwlzZXQgK3gKCWlmIFsgJDEgIT0gJDIgXSA7IHRoZW4KCSAgICBlY2hvIC1l ICJcbkNvbW1hbmQg
JDMgcmV0dXJuZWQgd3Jvbmcgc3RhdHVzIChleHBlY3RlZDogJDIsIGdvdDog JDEpXG4iCgkgICAg
ZXhpdCAxCglmaQojCXNldCAteAp9CgppZiBbIC16ICRkaXNrIF0gOyB0aGVu CgllY2hvICJEaXNr
IGZvciB0ZXN0IG5vdCBzcGVjaWZpZWQuIFBsZWFzZSBzZXQgXCJkaXNrXCIg dmFyaWFibGUuIgoJ
ZXhpdApmaQplY2hvICJEaXNrIHRvIHRlc3Q9ICRkaXNrIgoKaWYgWyAhIC1k ICRWMU1OVCBdIDsg
dGhlbgogICAgbWtkaXIgJFYxTU5UCmZpCgppZiBbICEgLWQgJFYyTU5UIF0g OyB0aGVuCiAgICBt
a2RpciAkVjJNTlQKZmkKCiNzZXQgLXgKCiMjIyMjIyMjIyMjIyMjIyMjIyBj bGVhbnVwICMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKI3VubW91bnQKdW1vdW50ICRWMU1O VAp1bW91bnQgJFYy
TU5UCgojc3RvcApyZXM9MQp3aGlsZSBbICRyZXMgIT0gMCBdIDsgZG8KCW1k YWRtIC1TcwoJcmVz
PSQ/CmRvbmUKCiNjbGVhbgptZGFkbSAtLXplcm8tc3VwZXJibG9jayAkZGlz awoKCiMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIwojIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIE1BSU4gIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMKIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjCgojIyMj
IyMjIyMjIyMjIyMjIyMgcHJlcGFyZSBkaXNrIGZvciB0ZXN0cyAjIyMjIyMj IyMjIyMjIyMKCnNm
ZGlzayAtdU0gJGRpc2sgPDwgRU9GCiw1MDAwMCxMCiw1MDAwMCxMCkVPRgoK dWRldmFkbSBzZXR0
bGUKCglQMT0kZGlzaycxJwoJUDI9JGRpc2snMicKCW1rZnMgJFAxCglta2Zz ICRQMgoKCW1vdW50
ICRQMSAkVjFNTlQKCW1vdW50ICRQMiAkVjJNTlQKCglvcGVuc3NsIHJhbmQg LW91dCAkVjFNTlQv
dGVzdDEuYmluICRGSUxFX1NJWkUKCVNVTTE9JChtZDVzdW0gJFYxTU5UL3Rl c3QxLmJpbiB8IGdh
d2sgJ3twcmludCAkMX0nKQoJb3BlbnNzbCByYW5kIC1vdXQgJFYyTU5UL3Rl c3QxLmJpbiAkRklM
RV9TSVpFCglTVU0yPSQobWQ1c3VtICRWMk1OVC90ZXN0MS5iaW4gfCBnYXdr ICd7cHJpbnQgJDF9
JykKCgllY2hvICJTVU0xPSRTVU0xIiA+ICRTVU0KCWVjaG8gIlNVTTI9JFNV TTIiID4+ICRTVU0K
Cgl1bW91bnQgJFYxTU5UCgl1bW91bnQgJFYyTU5UCgojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMg
cnVuIHRlc3QgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCmlmIFtbICQxID0g Im5hdGl2ZSIgXV0g
OyB0aGVuCgkjY3JlYXRlIHZvbAoJbWRhZG0gLUMgJE4xIC1lIDAuOSAtYW1k IC1sIDAgLS1jaHVu
ayAkQ0hVTksgLW4gMSAkZGlzayAtUiAtLWZvcmNlCglzdGF0ICQ/IDAgY3Jh ZXRlX3ZvbDEKZWxz
ZQoJI2NyZWF0ZSBjb250YWluZXIKCW1kYWRtIC1DICRDT05UIC1hbWQgLWUg aW1zbSAtbiAxICRk
aXNrIC1SIC0tZm9yY2UKCXN0YXQgJD8gMCBjcmVhdGVfY29udGFpbmVyCgoJ I2NyZWF0ZSB2b2wK
CW1kYWRtIC1DICROMSAtYW1kIC1sIDAgLS1jaHVuayAkQ0hVTksgLW4gMSAk ZGlzayAtUiAtLWZv
cmNlCglzdGF0ICQ/IDAgY3JhZXRlX3ZvbDEKZmkKCiNjaGVjayBzdGF0dXMK Y2F0IC9wcm9jL21k
c3RhdAoKdWRldmFkbSBzZXR0bGUKCmxzIC9kZXYgfCBncmVwIG1kCmxzIC9k ZXYvbWQKCmxzIC9k
ZXYvbWQgfCBncmVwIHZvbF8xcDEgPiAvZGV2L251bGwKaWYgWyAkPyAhPSAw IF0gOyB0aGVuCgll
Y2hvICJFcnJvci4gUGFydGl0aW9uICMxIG5vdCBtYXBwZWQhIgoJZXhpdApm aQpscyAvZGV2L21k
IHwgZ3JlcCB2b2xfMXAyID4gL2Rldi9udWxsCmlmIFsgJD8gIT0gMCBdIDsg dGhlbgoJZWNobyAi
RXJyb3IuIFBhcnRpdGlvbiAjMiBub3QgbWFwcGVkISIKCWV4aXQKZmkKCiNt b3VudAptb3VudCAk
TjEncDEnICRWMU1OVApzdGF0ICQ/IDAgbW91bnRfdm9sMQoKbW91bnQgJE4x J3AyJyAkVjJNTlQK
c3RhdCAkPyAwIG1vdW50X3ZvbDIKClNVTTFfQT0kKG1kNXN1bSAkVjFNTlQv dGVzdDEuYmluIHwg
Z2F3ayAne3ByaW50ICQxfScpClNVTTJfQT0kKG1kNXN1bSAkVjJNTlQvdGVz dDEuYmluIHwgZ2F3
ayAne3ByaW50ICQxfScpCgppZiBbWyAkU1VNMSAhPSAkU1VNMV9BIF1dIHx8 IFtbICRTVU0yICE9
ICRTVU0yX0EgXV0gOyB0aGVuCiAgICAJZWNobyAiRXJyb3IuIFRlc3QgZmFp bGVkLiBtZDVzdW0g
b2YgZmlsZXMgbm90IGVxdWFsISIKZWxzZQogICAgZWNobyAiVGVzdCBQQVNT RUQhIgpmaQoKIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMj
IwojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMgRU5EICMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMj
IyMjIyMjCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMKCg==

--_002_BE2BFE91933D1B4089447C644860408068C4429Dirsmsx503gerc or_--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 14.02.2011 03:11:49 von NeilBrown

On Wed, 9 Feb 2011 14:33:01 +0000 "Wojcik, Krzysztof"
wrote:

>
> Steps to reproduce:
> 1. Create partition on disk (for example: 1 partition, size=half of /dev/sda disk)
> 2. Create filesystem on partition (ext3)
> 3. Mount partition and create some control data on partition
> 4. Unmount partition
> 5. Create RAID0 on disk (mdadm -C /dev/md/vol_1 -amd -e 0.9 -c 64 -l 0 -n 1 /dev/sda --force)
> 6. md127 and md127p1 appears in /dev as expected
> 7. Try to mount md127p1 and verify control data on them

I couldn't get this to fail for me.
It is possible that there is something subtle about the precise device
geometry.
Could you send me
sfdisk -l /dev/sda
(or whatever device you are using)

However when I ran the script without requesting native metadata I did
get some results somewhat similar to yours - and they were not consistent
which is an important similarity.

This patch should fix that particular problem. Let me know if you
can still produce any of these errors with the patch applied.

Thanks,
NeilBrown

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 0cc30ec..6818ff4 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4138,10 +4138,10 @@ array_size_store(mddev_t *mddev, const char *buf, size_t len)
}

mddev->array_sectors = sectors;
- set_capacity(mddev->gendisk, mddev->array_sectors);
- if (mddev->pers)
+ if (mddev->pers) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
revalidate_disk(mddev->gendisk);
-
+ }
return len;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Single-drive RAID0

am 14.02.2011 18:04:38 von krzysztof.wojcik

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Monday, February 14, 2011 3:12 AM
> To: Wojcik, Krzysztof
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Single-drive RAID0
>
> On Wed, 9 Feb 2011 14:33:01 +0000 "Wojcik, Krzysztof"
> wrote:
>
> >
> > Steps to reproduce:
> > 1. Create partition on disk (for example: 1 partition, size=half of
> /dev/sda disk)
> > 2. Create filesystem on partition (ext3)
> > 3. Mount partition and create some control data on partition
> > 4. Unmount partition
> > 5. Create RAID0 on disk (mdadm -C /dev/md/vol_1 -amd -e 0.9 -c 64 -l
> 0 -n 1 /dev/sda --force)
> > 6. md127 and md127p1 appears in /dev as expected
> > 7. Try to mount md127p1 and verify control data on them
>
> I couldn't get this to fail for me.
> It is possible that there is something subtle about the precise device
> geometry.
> Could you send me
> sfdisk -l /dev/sda
> (or whatever device you are using)
>
> However when I ran the script without requesting native metadata I did
> get some results somewhat similar to yours - and they were not
> consistent
> which is an important similarity.
>
> This patch should fix that particular problem. Let me know if you
> can still produce any of these errors with the patch applied.

Unfortunately issue is reproducible with path applied.
I tried to reproduce it on other setup (other PC and disks) also... issue exists :(

Interesting observation is that when I stop array just after creation and then reassemble it again, everything work fine.
On older kernel version (I tried 2.6.34) issue is NOT reproducible also.

Regards
Krzysztof

>
> Thanks,
> NeilBrown
>
>
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 0cc30ec..6818ff4 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -4138,10 +4138,10 @@ array_size_store(mddev_t *mddev, const char
> *buf, size_t len)
> }
>
> mddev->array_sectors = sectors;
> - set_capacity(mddev->gendisk, mddev->array_sectors);
> - if (mddev->pers)
> + if (mddev->pers) {
> + set_capacity(mddev->gendisk, mddev->array_sectors);
> revalidate_disk(mddev->gendisk);
> -
> + }
> return len;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 15.02.2011 01:01:41 von NeilBrown

On Mon, 14 Feb 2011 17:04:38 +0000 "Wojcik, Krzysztof"
wrote:
> > It is possible that there is something subtle about the precise device
> > geometry.
> > Could you send me
> > sfdisk -l /dev/sda
> > (or whatever device you are using)

You didn't include this information...

> > This patch should fix that particular problem. Let me know if you
> > can still produce any of these errors with the patch applied.
>
>
> Unfortunately issue is reproducible with path applied.
> I tried to reproduce it on other setup (other PC and disks) also... issue exists :(
>
> Interesting observation is that when I stop array just after creation and then reassemble it again, everything work fine.
> On older kernel version (I tried 2.6.34) issue is NOT reproducible also.
>

All very strange. And as I cannot reproduce it, it is very hard to debug.

Maybe some daemon is accessing the array at some awkward time and causing
different behaviour for you...

If it is repeatable enough that you could try 'git bisect' to find which
commit introduced the problem, that would be helpful but I suspect it would
be very time-consuming.

It might help to put a "WARN_ON(1)" in the place where it prints "detected
capacity change ..." so we get a stack trace and can see how it got there.
That might git a hint to what is looping.
Also a printk in md_open if it returns ERESTARTSYS would be interesting.

Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Single-drive RAID0

am 15.02.2011 17:30:05 von krzysztof.wojcik

--_004_BE2BFE91933D1B4089447C644860408068FB347Birsmsx503gerc or_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Tuesday, February 15, 2011 1:02 AM
> To: Wojcik, Krzysztof
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Single-drive RAID0
>=20
> On Mon, 14 Feb 2011 17:04:38 +0000 "Wojcik, Krzysztof"
> wrote:
> > > It is possible that there is something subtle about the precise
> device
> > > geometry.
> > > Could you send me
> > > sfdisk -l /dev/sda
> > > (or whatever device you are using)
>=20
> You didn't include this information...

Disk /dev/sdc: 30515 cylinders, 255 heads, 63 sectors/track
Units =3D cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/sdc1 0+ 6374 6375- 51207187 83 Linux
/dev/sdc2 6375 12749 6375 51207187+ 83 Linux
/dev/sdc3 0 - 0 0 0 Empty
/dev/sdc4 0 - 0 0 0 Empty

>=20
> > > This patch should fix that particular problem. Let me know if you
> > > can still produce any of these errors with the patch applied.
> >
> >
> > Unfortunately issue is reproducible with path applied.
> > I tried to reproduce it on other setup (other PC and disks) also...
> issue exists :(
> >
> > Interesting observation is that when I stop array just after creation
> and then reassemble it again, everything work fine.
> > On older kernel version (I tried 2.6.34) issue is NOT reproducible
> also.
> >
>=20
> All very strange. And as I cannot reproduce it, it is very hard to
> debug.
>=20
> Maybe some daemon is accessing the array at some awkward time and
> causing
> different behaviour for you...
>=20
> If it is repeatable enough that you could try 'git bisect' to find
> which
> commit introduced the problem, that would be helpful but I suspect it
> would
> be very time-consuming.
>=20
> It might help to put a "WARN_ON(1)" in the place where it prints
> "detected
> capacity change ..." so we get a stack trace and can see how it got
> there.
> That might git a hint to what is looping.
> Also a printk in md_open if it returns ERESTARTSYS would be
> interesting.

In attachment part of logs from kernel with WARN_ON(1) and value returned b=
y md_open()=20
(line preceded with "##### KW: err=3D x").

I am trying to look for in new areas. I've run:
Udevd --debug --dedug-traces

Logs from udev and kernel in attachment.
Maybe it will help to find solution...
It seems to udev adds and removes device in loop...

Regards
Krzysztof

>=20
> Thanks,
> NeilBrown

--_004_BE2BFE91933D1B4089447C644860408068FB347Birsmsx503gerc or_
Content-Type: application/x-compressed; name="kernel_log.tgz"
Content-Description: kernel_log.tgz
Content-Disposition: attachment; filename="kernel_log.tgz"; size=1396;
creation-date="Tue, 15 Feb 2011 15:34:23 GMT";
modification-date="Tue, 15 Feb 2011 15:31:32 GMT"
Content-Transfer-Encoding: base64

H4sIAJ9jWk0AA+1aXW/bNhTN837FBfqyoUsqSpZsGfvAUGDdMKwbhgJ9KAqC IimbsySqJBUn+/W7
lGOvDZKWVhskXXkAQxRFHl0eXlI8SDbSdLKhjV6duQt3cidIEMVsNl4R167p bFaQE0LytMhJPp9h
PUlneXYCyd2E8y4G65gBODFav3f4H3r+meJnWQHJgaTLdL7MFrDaNKw6Jeni lBACmzE7lvALM2LL
jISOtXIJe3wV1vt3LYZGWmhUt5ECVLcEeeFSMExI3YFzLQjT0k1r6Vo2vTT+ FlTKKWtWmlbKge0E
7XlLtbVjuVUX0hzurHyzv1IhzxXHQGt8n+Yb4UuU8QbY4NbU9HzlOw0dlkD1 5wWwmvaMb6QD3g+1
QQquOyvNOXPqXB4qB6yy2PC/ml5vsYphG8Z7Ra+qocUB1NAqbjTXQkKNPTEU 3YNoaavFGOlaMOqf
ciy16lqVEg61USI51KvOyebdVru7rZD9XpxRMbVIyFjgGqfLP3GqRUWxBFYP nRjrRz7KVj0Yh01b
bUESXIsSem77jQHXt9jR+utYrhQ22fVauavpYCuJE4Qi70jG90mjNDVsC+rF 0z/oFgcyFs5lJ7Sh
duh7bdzYvlEV2BVUg3OYA4Ot1kqA/w1rruiaC5D7ghWjbtxw6kgiVO2bj++T QvhUyqCtOONrCX9X
AmrWQY/iS2u1ASUkiqPoSnYYHB/vx77MsUNl729aZs5lg4mC78VcrQ5Xx8By q8Yg3FqaljX7K7WX
FtbbVneBa+FPJZaQpnmWfAtct+0SWsFECy+YVxefPdsvrpf4S8+Ks2xxanj6 GB6lZeA7nuKswAuD
uboM7AGvvquvsCBJXRZl+cNr+BFQUr6hQtkNteofFG7NupV8nFzMyifJxSKZ RJ/lC8lHetxSOmob
vUX919TLobvHnhfJy9DRXicvCbuBvBuaBqlJjtRk/gBlSdNqVsmRvhVU93JU gngl5LRwWZ7kIx+l
VbPBfRHT3SEpl0ia5dMmD1mlvImVVPOPoi3n85H2XdLap0KW8YmkjGdvk16p 6jnn0yZJ8IyI3fBx
l6O2Vx0dOv+hQd60QOK0mphcvNjpWgn8XL0ZlPEJlfu5EukDGT5SVml9A2XB p3NySWpylVFCds5c
7llJlnlBs8VE3ozveP2hRQm/xTtNa9X0+5WaT2MWbDbbCVurTtn1Pt6y8ptL MW22BF/ku3DFLsiD
CtIvrEJO27SqhOW7WFu1Wjtas6HxK2vmE6uclKt3twjknLHdDjueK2gt/Pi5 8LKKabsgF3Vd7mXF
j/Ve1ZwhqZw2VVwmbPeNeYuQjJMvJhEm6SKr9oROtpTj+HGqrPPfLk/uRSWh op6enr4CPHGB82cA
SHg9T7J5mbHFLCOFgNfYIJCqFSQtliCkkxyPJ8AZHoGVu4TdJw9qo1tIwGkg RZJki5KkeIwMJH8U
DPjtJXoGY76H4D3mKvKeQH99lss7jOf/xn36Fl4BHxzgwVeOKXRAINXLn/56 /uvzZ0s8eUNtn1R+
w/B27YwvyyL/4KHq628C3xNmVm/rHc1qNKtfmlm9bS0czOri483qbe+43aze 1uMTubIw+olmNZR8
gll9CLIcYVYDwz3SrIayHuUqQ0mPsFVhak44UIdmwRGu8r6Gf6SrDOM83lWG 8h7vKsOYj3SVgaTH
usow2uNc5T0vgqNcZWAWHOUqQzMr2FWGEU50le9xAu9xlfImV3kb1Sdxlffh hh6aq4zuLLqz6M6+
cHc2y6I7i+7sc3RnR/4pMZq+aPqi6YumL5q+B2L66i/Q9N33P2xGRERERERE RERERERERERERERE
RERERERERERERERERERERERc4V9pK202AFAAAA==

--_004_BE2BFE91933D1B4089447C644860408068FB347Birsmsx503gerc or_
Content-Type: application/x-compressed; name="kernel_with_udev.tgz"
Content-Description: kernel_with_udev.tgz
Content-Disposition: attachment; filename="kernel_with_udev.tgz"; size=2855;
creation-date="Tue, 15 Feb 2011 16:24:37 GMT";
modification-date="Tue, 15 Feb 2011 16:20:55 GMT"
Content-Transfer-Encoding: base64

H4sIADJvWk0AA+0d2XLbSC7P8xVdNQ/erVlaPETqqM3ueuJMNpOz4uz4ITXF anY3pR7xGpKynfnw
fV40JXkUx5Kal48NUKXiIQoNoNFoAATsSCbLK7+4zKnkg2Uh8mKwuEx/Y3Ix WIg8EZF/Kcu5v+Ti
4ri8Kp80ARPAGw6rI8CXR8vyPHf0xLJc23NtBy6emLZl2+YTYjYarSYsi5Lm hDzJ03Qvd4e+f6Tw
kwiI5RLLng7NqTMis0VEA8Oyx4ZlWWSlAlNCPv09XMPYMkNKmfOPX8k/SRAt QDH8NBPJD+aVOTCv
RuZ3DVDanDkWr1D6Ob30i0wm/jKJUrYAvLYHiO2gCWIznDBPrGjlPmW/L2Uu AKUrACW3m6HsnH1A
GdjhLSg91hwnE1ZorUTqc5GU+ecNVstxlECdcUO8DlvhTWgsJKcl9cvUD2WU Ae7hBFC7zTBzOhyu
BBvKRBbzDb2TAHBaXrPZ4mzsrsjlKyKvpSBGgNYTo0ZoA5O6K1pjOZuXfkiX Uan4V4o1aaSr/S0C
MaJ0UiGmEaDzQ674Z1yJlYtmWsDDcLIRa/G52EjVpYBUNJsqJkxKK5xbCK1q 8nkjhKY9doINwlLE
PgP+YaqKMqPlXCFXQrV0hWoYxiciEk7KnDJBRDhmAQ1cZ+IOqeUy8is8oIkq 5pbtTQkXpWCl4ITR
jDJZfiZsTpOZIGGexsQkZUoszzSd8cSyYa/URP69NpBX51Mi8vwp0bYxa8oz i2S6s9wnPcYWfCJs
WZK5yEU1Fdegier85MPbl29fTAktSVgMArXwfOX3sOnEc2FmhLqWxcIv5B/C X83UxuSNzb/8VXOc
f9OcX1IgUtlPkOgaNH/9JuXLSBQkkskCFEcmILCr0iY55SJNSFnGhOexv4gL fy6iTOTqkkib+TSa
pX4gS1Ik3M9Y7KdFUZ3H8krk11eF+H1zVNxL0PQkhPFAGlydwS4aEboEpzDP 2Ez9aJnAGZHZhUdo
6IMiL0RJWLYMc0DB0gS8ygtaygtxfbNyNDO1iDZ3svQSblF4hrJM+uvbJAYG QjCxLE9ZymFdwC+B
lDQjPPbjlFeUzjn11bcMzmJ545bk5fUdmZQiIsrVNb98anV1yUW2EQ6pnvXp bHWnlDFIUklRjk1r
/eWsrFCTMovhgUIdq/NApkX1LEthlgXYIVMQ+fHZO/8SiKlOLsCMpLlfLLMs zQFLukx49XQ1PJ0J
v7LUpJiRYFmWMLEZK7JFTkBwMlXbA8lLGCCGkaoT9Vt1EsmALItgLjlRn+Wc SX/OQE68EhfLmV/C
pihDIjZfweMrQjlXquSQOGAUtJ38FnASUhgahC+KIgUBcAHCkf5MJEAHq66r 3yonYHMzUxcxzS9E
BIoCo4CuBtfHkpKCFbKipoS1GtNoc1T7CJlfxmmiuRbeSz4lE29s/o2wNI6V WaU8Jh+pmh/46sVm
bZ3Dxz72jp2xkTP7B/K9PdEc4hnMA/mo7P20of/pTVb75CH70Qi9444Fq9CD RUn8Ikov1dbmK3Gk
avscK690osvtTeQTi96CPFlGkdo8XbV5NnOf+hWLbQfDYOX1x3zjSIwtJYlm 3k5IXdNd+9JrD30m
lLvHlLvnuE29fleI27BawagV2slotB1MrJGGShUchz2QoAdjPoz5MObDmO8x x3wcYz6MyzAuw7gM
47Lb4jJrE5eBhwNMY1yGcRnGZd90XGZ7X8dllUN2H3FZWJQ0gI3oE5gq+9cp eClFCS5YlM5mMpnB
npawUoKJh4jBdIewN+ViJsGnzEUz1/RhRnw3pRCqPY8cDYDAgVr+g+CzIfkA Ngjj/PSZf35qu6Z5
cvLzj4Zp/uycmHDHOH928ottjkfgfA+NjOalc/Svo+KSZkf3Fm5+NblpnCnn 7qgFT+TpU3JUOcOZ
1YyzluFub0xt/T7mxnIpuWGKYOgFtj01XS8YCqDIMkeTYExHU4ebY9cLgwpD U0m0jdF7nODBRRr5
VtM5bpcm6H2K1eQOXJfZIZ+YxshhoTF0TGEELJjAZeiZ1pCagd2M+y52j/5m lmYQtwyaTWurhMoO
I6s8eLCUg+p4DzmZHWQBnrBQdMFJUwveOK2zgyYuguXsmqp1cdqgutuMxI4S RTvIheBtRaya2kGw
LAZwR5fQ/UknoZN02inFi6ys6FLbuzq9z+TVDiJfn/z4/PXTszNv+OZUkapL Yx85sL0kplmp6FOH
HlJpO83g8dun/63li2hg6tMB0GJEd8+twUtnO50OA3pby151ekNVcPHuTOlU XJ2nB9cnKsk3piSv
PrysFGSRS1QOVI4vleP05ONJtbmDe4zKgcqxVo7ZooAIW+SmdSxni+PqLckx jDJVUlEfp2r9GGTL
YNP9obRonsZi+1bLwe0dgw//HHy2CCIOcaPcHv7Pmz1xb4N/LiNeucXrs55Y tRWXkVzFfKuzliMN
d44EWIo0LNUbTTXc9mXLMZ2dY8J9g7GZH211FVWDb1/3xvGz9y+MMhdRJAuW L/8I6Gfj5sT66+8b
EmGN7GN7fOyOjx1zOsiuKsmqQzt03rHludPBy7N3Cp86NMzZwk8HBaymwdl/ zp4bZ6+fn8Hjxtl7
y3jxZrB9efrLqXE19nxvCN+oK1gbRapGh/PaZoalMBtX5XaiPBK00E6TY7EA FgtgscA3XiwwxCJu
LBbAYoFrtFgsgEXcWMSNRdxYxN1zEXeIRdwYl2FchnEZxmW3xWUuFnE/2Lhs OxHn3UUFK0Z8GPF1
W+DnPYyS41a16V8tw25rje2GLHVVG98pSy3eBDeWQ5sYvce5Xb+TbshWt5X/ vcxx9YbcYTwIXYsa
E+5xY2gK2wioOzKCiRixke3SoaNdGNlvm0C301v/jf2WKaxTGLwDRfsi3g6b FbboalHIuwNjo1rb
ndTVLJDdgaduDeteNPp1pjvV+WZRz0Gjo4GpT1OuxUg7A9ppB8oBEfVsCbtr Odkl6xadEz16jM3r
Znvu8Wi39vpu9biH9dxrm0hPBqKHDpG7NhN7M9+eWbeTpBvr0HsvyVcWok7R 9F11k3RkIho2lDz2
Lf0+FlV3K2GvsjYt4kZ/7/9aOe6+iPu2we+0iLsO9+2KuOuw2q6I+7aR+i7i vm3MuyvirsdxT0Xc
W0R0UcR9C7pWRdzbWfB7KOL2sIgbiwWwWACLBVoWC0zwL3E/3GIBfKWP796x 2hqrrbHaGqut763a
2rOw2voe6MHgDIMzDM6+8eDMweAMg7PHGJxhvTXGfBjzYcyHMd/jjPlsjPkw LsO4DOMyjMtui8uG
D6HDdqscYOI++lbSriK+m1J5AJ2KXTcOr2b7Qfx3lM50ojf27vz/pLSI0Xuc 43b/IKVummB817Pb
+C/73qS0o4TGnQlgR4WqLlu1EiqHmNLohNSlq0ZSQpOqfc2VWlQ1iWg1aavR YKkpwDq98ZpEavVs
3t/8HmwD1SWtTvJKk7ZDraV6pNXPgdUib3fLqi559VNp2mby4F+416OxZlKu AXlduhuaPNXNCTYS
+i7/QY/GegnGFmLv1w/oYwvQ7zrRE3Wt9GgtA6HTtKtpKmrlW+/aSNTI3D4K A9EwcXwnZmJ/Ftq5
LQv9kKxDJ5nv/i1EFzn0WqZiX/fuTqXdk4zvzwTc84rtdFHdx0roTln3KtS+ DltUjm9WOfrpsK07
eOcdtl1xf7jDtitWD3fY1h2piw7bumN222HbHcctOmw1idDtsK2J7mCHrSa+ vjpsDxusQx22ztS8
BY9hkDcnH17B8bsnCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICP8DRI5Q
KQDIAAA=

--_004_BE2BFE91933D1B4089447C644860408068FB347Birsmsx503gerc or_
Content-Type: application/x-compressed; name="udev_logs.tgz"
Content-Description: udev_logs.tgz
Content-Disposition: attachment; filename="udev_logs.tgz"; size=5751;
creation-date="Tue, 15 Feb 2011 16:26:16 GMT";
modification-date="Tue, 15 Feb 2011 16:25:55 GMT"
Content-Transfer-Encoding: base64

H4sIAF1wWk0AA+2dbW/jRpLH5/V8Cr5TAlgWSUmUZcCHzSW+wwCb2cNmN8Bi dyBQIm3rRhK1JDUZ
f/trknqi2CJZ/VRFn5Uglj0D59fFVnV39b+qdkH4bbaKnpPb9Hv6Qc/LZi9v NMq/slf569AdDT3v
g+OMXW/M3k8mH2zHHQ69D5atiaf02iWpH1vWhziKasff9Ocdfd3e3n7859ge u1+sdfI8+/cu3IWz
5SYJ4/TeSsJ/W0P3zrPyHwc3Vs8Pgp7Vm6+ixdeehfk6QO+y+Rt+CzfpLN5t zpCfovhrhrxdBtY/
p97I/nKBf2PZ7G8vok2QWNEqMAOdgxTQmygIZ+uv7Mu9lX/5YcB+PLhN19u+ O572bQbosX/Y1x/Y
9zf2jz+aYGwPvXhZX4fGYW0DHf2x4UCzf5GRT9BsIs+2cfQc++t7qzdI5svN YB34wdrq94Mw9Zcr
9ib8vo3i1LoYifkPZSN0z/ohSYNol/5o9X79Zfbnx98f//wQ+8sAAVYU+pfH 3z/9/Pjbg4Pp9KDQ
P//l899++vT58a8P+SRZB4PlOlkbtjoU+tfHX/+TESPODQHov//90y8Pdjgf eXPXvbfH3nwUOu69
Y0+m8zt/cj8M7Lux9zTXOiiBOf35p18fH75FqxnavG4BHYfpLt6EgfXHMn2x 2G4t3SVs6UZ8lRaX
eLcKk9lzmM42/jq8t9gWw0pe16vl5qvVC5bJ18H8tb8M2Gj6u90y6LeYJv2t H6eqH0l7aOYo8jmx
RfV2JWje9JivvrKtXT/KR2T1t/hLYVvo8w/ip19m//Vb4UDG44X7FEzt/mS4 eOqPhnbYny/mU/bt
k2c7I9+eu/qeiCD07PHzz3jgAtC/P/71t09/+fzg3GJNEAHov/3jfx4fwu+p 26k5/dtP//348LRk
nuY1ScM1ra3pHrpji0vmoNlQllG8TF8fHBuV9OwFXxGztXCA6vGuTI8nNgnm s+U6P12tA8f1to4l
s45bp/XUAo/eWvvbbRgPevXQg9VyPsiMPzjHLz6TYRyzzyT7C9mfZwES9iB2 32fLzTI9fqd5vy0N
XRzjwz/Y+T3apMwTWvZ3zx6PAttaxKGfhoF6foXQq+j59Kn1dJparaWfls+z zIE/9AZhuih+Q/af
2+zPesrGoRA6e7P10xdGzN6qQ9QKzdbHAzR7Sweauzg6+ugaoLmLyyaysvCe lX3HvFl6w2BXK2uX
hNbXkMGvij/p7T25sU1ICTqY58Ts7XJRMAdzK/tgWWnErOwH+7NL/gyC+eBf 39nCkP/lJHv7bRmn
O3+Vvc1D19mbfDzHN1vn3vocWclu8VL83ihma00cLtIofhWEzqOmbO2+L1zs cvNsFUyFwXv7oFJh
1hu2UP1vFD9kgWprvdywtzZ7w/7ig+157C1b8LKfPLMvnkZLXwmq7zGL4LSH HVGvgz4Lql9Ao4en
WwXVT9A3loePfILO3ADb9ATh97MJvf++d/bxy/5eMsg2avnnLdvzFR8z4LZP 5ENc2eXBoNc56X6v
KfX/x7F0ZuDsbZuNsarhiVo6/4XmbVyGPn0Qd9uA7YJn+2NWwnYX+Q9URSKj p8II2UAH+1EO8iEW
phi0GNz1FTGZzV/3y/lTtNsEhd3PFjAdn892z+EIXdg3s+UB0tkvh0mxPSq2 GSQCvjXQLZ/iE9s/
GB4LF3oRrdmvC60fol1ssTXmR+twjAJMySxM8h8PWqI6XGhJw+WzKfVj9vk4 27a++ImVvoTWy/L5
JUzSkx2cTCBQHIKtZQqBzh3H3kGcOb2jy8g/dHJjYdvb3u3tgP0r6/0EXN75 PYYKByYJLevySqu7
gTNiW5dH4rpIkcszO5Y35PLODafdgYlDt3J552PZOzDT0YMStMAuDxBdV+wZ de3yIGcD8GMS3eWh
XmIo3uWZGcsbcnkChjPpGYV2eYCxqNvacaC3fpLMws23WRrNEvaww/Q+/1kY WH3Hmr+m7PPIAIo/
YmOI4udBEe4dBOvBerdKl1lAvRAG924UkMlBeyOvSv2nHPspDsMgTL6m0Xbw wib3SdCslVvQ0n86
N3XuqdfRZsnct24jl6Cvi76Xm2XycrixoHE73iivn3RPXj+pyOtHVOT1o5by eudCXu9gyut50Dx5
vUNJXs+HrsrrHUry+pGMvB7hhNsITVZeD4CmI68HQNOR1wOg6cjrAdB05PWw OU1EXl8PTVQBOYKI
CQWC06qltO2hj+ElPDXvJbSAvB7PVTdCX5HXDxfB/Gns+P1p4AX9kR26/bk/ nvTn03CymLhjfzTU
50EEoXN5PRq4ADQReT0Mmoi8Hjg9aMjr66E7triQlteDVsQ8kIfq8a5MD468 3pWR17sneb1rgUfP
l9dX53QH5PUy0GjyejXQhuX1yixtUl6vBtqwvF4NtGF5fWtoSvL6a4sLTF5v bgNVgtYvr3fVyetL
UdN28nqXJ693TMrrG4Lqe8wLeT1WRL0OuiKvd4nJ6xuC6idoSvL6kXF5vSvy Ia7s8sTl9XL/fxxL
HyQ0bTbGqoYnaun8F5q3cRnajLzeba3Bqh3c9RURQ17f8jkcofXL69XtTWqg Wz5FWXm9wFi40PLC
K1e/8OoSWtJwHA2Wq15eP9Ivr3erGizxOS7g8s7vMVQ4MElolfJ6necYqMsj cV2kyOWZHcsbcnnn
htPuwMShYfJ690Jeb3iCS+zyANF1xZ5R1y4PcjYQk9cL7PJQLzEU7/LMjOUN uTwBw5n0jEK7PMBY
1G3tONDdk9fXQxOV18MtTUBeP6oTfXdRXn93ktfH4Tr6FhJQ2DfI6+8q8vq7 L1V80wr7jwVIKZaX
I5EvlQGGplD+RcDS+OVfZCyNVv6FQa/9dPGS336WLmwPW6Pjbwgi5rA3UWqF 35eJptNU4+sAfTq5
FJ7hzN7XrhKRZZt3poLqKmvW3DUctzaRmYI1be+gj9DVk0ufbNEaLvQmu75/ CuNww+byKnxKb4oZ
ToRZZE4TKUqiZE6XK5IokUg0Qred0xSqkkDnNAVmGT+NXHVCtZ8GlZwQmP3C fhqz7ISon8YvlXHX
xbhHPbQ3dinGPeCWJhD3uKs7jXcx7jHtXtxjWol7TKnEPaZicQ9cDRMYmoIu T8DS+Lo8GUuj6fKm
LeMeLqW4x1Qo7oGc2jc1FfdQKSackoh7uLC4x9RM3EPZfOJC64l7KFZAwuY0 EbWYkjldlorpj3tA
5jQFuRh0TlNglvHTyHIg1X4apAUSjXuI+GlMPZCon8bXME27GPeohyYa94Bb mkDcY1p3Gu9g3GNq
n+Ieixd/80w/7sGQL+IeY/tLFR8j7sFALs6IyWvSsIAN/Dj2X2dZQjODzw+M iXbYS+jGGpDTPqM9
qwE5vWHfI9aA5EJf1oAsQROoAXkFulwD8gBNpQbkuK7feG0NyHwkOIV2aqGp 1oCEQJOpAQmBJlMD
EgJNpgYkBJpMDUjgnKZRA7IBmmaZruPioqEGpLZ6ee2gDxEP9AqQ9dOjpgYk 0lLYFvrKnHaxgM+h
O1d67io0qDqQwclSgi4OK8Wp6/5wQVQbhOtZ/iorG/RqLTdW4Kf+3E/CG2ux Cv3NbqsbWuCaufWt
oPJnIAYtcymkYKyilj5G/THsXT1utSoedSwddSoclR3GjJSOqjkjbuMwCeNv YRE1LvPOw4WfuZBl
mufuLaI4CyjnteeM3Dzzpofekkaa5jSopBHmnBaoDoTv8rRf6DffFrUfW3lF RKwOBHkcR2it1YE0
FIK/At3wLCWqAsmOgQstkTeuNV+8FlrYgNXkcS2p40eXV8obL+ZHHipXVSNI 5bTmQx/X8MNuWTH/
RQo8dEACfvp0LFfneSWgFZY0MhIWg5Y0IhGAFPTTOGN4Q376ZEBDnlcMGuCn 8ae1nJ8+8Z+XZdI+
mgN050QqDdAje0pQpCJgaXyRynFF5EonuihScTrX85MhX4pUhkR6fjKQdj0/ 7Yuenzam3oMHzev5
aVPSe/Chqz0/bUp6j6FMz0+Ea/JGaLJ6DwA0Hb0HAJqO3gMATUfvAYCmo/eA zWkieo96aKJ6j6E+
vYfiwi9QaBKVPcrQAj0/8TxII/SVnp9YBSdkoPOen2jgAtA0en4CoWn0/IRO DxI9PxugO7a4kBZe
gVZE1BI7ZejGnp+OTM9P59Tz07HAo+f2/OTMadGen2Y+lKLQZjqSKoZGb1Sq CNpso1J1ljbYqFQR
dGC0UakiaLONSttDE2pUenVFhDUqNXcMK0Hrb1TqKGtUWg71tmtU6vAaldoG G5U23QTsMS8alWJd
A9RBVxqVOrQalTbdBJygCTUqzaANNyqVLwQPhyZQCF7K0liF4EUsjd7coPxB 7EhNdf6KiNGotOVz
OELrb1Sqtjz5FeiWT1G2UanAWLjQ8i2sHO0trCrQkobjdLNylDcqzV2e5kal TkXKK+H9BFwejZL7
ylxeueq+Uk4+NLRRKXb1egUuz+xY3pDLOzecdgcmDg1rVHqhiDU9wSV2ebgd GXTs8kBNGYQtLdKo
FLO5gcJdnpmxvCGXJ2A4k55RaJcHGIu6rR0Huns5AfXQNBuVCliaQE7AsE6p 3sWcALd7OQFuJSdg
QiUnYNIyJ8C5yAlwMHMCeNC8nACHUk4AH7qaE+BQygmYyOQEIJxwG6HJ5gQA oOnkBACg6eQEAKDp
5AQAoOnkBMDmNJGcgHpoorLNCUQBidoUBQpNoutFGVogJwC3oXQt9JWcAKxm DDLQeU4AGrgANJGc
ABg0kZwA4PSgkRNQD92xxYV0TgBoRURtP1OGbswJcGVyAtxTToBrgUfPzwmo zukO5AQIQOPnBMhY
Gi0nQA204ZwAZZY2mROgBtpwToAaaMM5Aa2hKeUEXFsRYTkB5nZ9JWj9OQGu upyAUqi3XU6Ay8sJ
cEzmBDTcBOwxL3ICsK4B6qArOQEusZyAhpuAEzSlnICJ8ZwA+SbpcGgCTdKl LI3VJF3E0vkvNG/j
MrSZnACF/cb5KyJGTkDL53CE1p8ToLZ19xXolk9RNidAYCxcaHm1mKtfLXYJ LWk4jnDMVZ8TMNGf
E+BWhWPic1zA5dFoR6/M5ZU70ivl5ENDcwKwO7srcHlmx/KGXN654bQ7MHFo WE6Ae5ETYHiCS+zy
AFcCij2jrl0e5GwglhMgsMtDvXlRvMszM5Y35PIEDGfSMwrt8gBjUbe140B3 LyegHppoTgDc0gRy
AiZ1SvUu5gQMTzkBeYfKkEBaQENOwPAyJ8BzvlTxTacFfCxARLqr4tb3gEMT qFkjYmn0mjVSlsaq
WZNBr/108ZLffpYubA9bo+NvCCLmsDdRWjQAkrKX+OsAfTq5FJ7hzN7XrhJx taZl6I4U2jlCXztu
bSIzVXba3kEfoasnlz7ZSjtc6E12ff8UxuGGzeVV+JTeFDOcCLPInKZRSUXN nC6XUVEikWiEbjun
KZRSgc5pCswyfhq3VIZyPw2qkyEw+4X9NGatDFE/jV7fI4PuXNyjAdobuwTj HgKWxo97HL0H9zTe
xbjHqHtxj1El7uFSiXu4YnEPVA0THJqALk/E0ui6PClLY+nyMuhWcQ+XUtzD FYp74OYjlqE7IiY8
QuPGPVxY3MM1E/dQNp+40HriHmoVkMA5TUMtpmZOl6Vi+uMekDlNQS4GndMU mGX8NK4cSLmfBmmB
ROMeIn4aUw8k6qfRNUwZdPfiHvXQROMecEsTiHvUnsa7GPcYn+Ieixd/89yB uMe4EvcYfqnio8Q9
hpdnxOQ1aVjABn4c+6+zLKGZwecHxkQ77CV0Y+HKaZ/RnhWunN6w7xELV3Kh LwtXlqAJFK68Al0u
XHmAplK40qvr7F5buDIfCU51oFpoqoUrIdBkCldCoMkUroRAkylcCYEmU7gS OKdpFK5sgKZZW+y4
uGgoXKmtyF876EPEA71sZf30qClcibQUtoW+MqddLOBz6M7Vy7sKDaoOZHCy lKCLw0px6ro/XBDV
BuF6lr/Kyga9WsuNFfipP/eT8MZarEJ/s9vqhha4Zm59K6j8GYhBy1wKKRir qKWPUX8Me1ePW62K
Rx1LR50KR2WHMSOlo2rOiNs4TML4W1hEjcu883DhZy5kmea5e4sozgLKee05 IzfPvOmht6SRpjkN
KmmEOacFqgPhuzztF/rNt0Xtx1ZeERGrA0EexxFaa3UgDdXrr0A3PEuJqkCy Y+BCS+SNa80Xr4UW
NmA1eVxL6vjR5ZXyxov5kYfKVdUIUjmt+dDHNfywW1bMf5ECDx2QgJ8+HcvV eV4JaIUljYyExaAl
jUgEIAX9NM4Y3pCfPhnQkOcVgwb4afxpLeenT/znZZm0j+YA3T2RSj30yJ5S FKl0sVHpcUXkSie6
KFLxuteo1KuIVDwijUoZSLtGpfZFo1IbU+/Bg+Y1KrUp6T340NVGpTYlvYcn 06gU4Zq8EZqs3gMA
TUfvAYCmo/cAQNPRewCg6eg9YHOaiN6jHpqo3sPTp/dQXPgFCk2iskcZWqBR KZ4HaYS+0qgUq+CE
DHTeqBQNXACaRqNSIDSNRqXQ6UGiUWkDdMcWF9LCK9CKiFpipwzd2KjUkWlU 6pwalToWePTcRqWc
OS3aqNRMK1Bp6FN/RHNeRBTaXFdShdDojUoVQZttVKoIOjDaqFQRtNlGpe2h CTUqvboiwhqVmjuG
laD1Nyp1lDUqLYd62zUqdXiNSm2DjUqbbgL2mBeNSrGuAeqgK41KHVqNSptu Ak7QhBqVZtCGG5Uq
KAQPhqZQCF7G0miF4AUsjd/cwDMgRVZeU527ImI0Km35HI7Q+huVKi5Pzodu +RRlG5UKjIULLd/C
ytHewqoCLWk4TjcrR3mj0tzlaW5U6lSkvBLeT8DlESm5r8rllavuK+XkQ0Mb laJXr5d3eWbH8oZc
3rnhtDswcWhYo9ILRazpCS6xy0PuyKBhlwdqyiBsaZFGpajNDdTt8syM5Q25 PAHDmfSMQrs8wFjU
be040N3LCaiHptmoVMDSBHICvDqlehdzAibdywmYXOYETGwiOQEMpF1OgHOR E+Ag5gRwoXk5AQ6h
nIAr0NWcAIdQTkAGLZ4TgHDCbYSmmhMAgSaTEwCBJpMTAIEmkxMAgSaTEwCc 0zRyAhqgaco2j4uL
rpwA1frf9tAkul6UoQVyAnAbStdCX8kJwGrGIAOd5wSggQtA08gJAELTyAmA Tg8SOQEN0B1bXCjn
BMBWRNT2M2XoxpwAVyYnwD3lBLgWePTcnADOnBbNCTDzoRSFNpOxoBiar1Q3 lCagENpsToA6SxvM
CVAEbTYnQBG02ZyA9tCEcgKuroiwnABzu74StP6cAFdZTkA51NsuJ8Dl5QQ4 BnMCmm4C9pgXOQFY
1wB10JWcAJdWTkDTTcAJmlBOQAZtOCdAvkk6HJpAk3QpS2M1SRexdP4Lzdu4 DG0mJ0Bhv3H+ioiR
E9DyORyh9ecEqG3dfQW65VOUzQkQGAsXWl4t5mpXi1WgJQ3HEY65ynMCcpen OSfArQrHxOe4gMuj
0Y5emcsrd6RXysmHhuYEYHd2V+DyzI7lDbm8c8Npd2Di0LCcAPciJ8DwBJfY 5QGuBBR7Rl27PMjZ
QCgnQGSXh3rzoniXZ2Ysb8jlCRjOpGcU2uUBxqJua8eB7lxOQAM0zZwAAUvj 5wQcFxeuUr2LOQF3
p5yAvENlSCAt4OMte3388P56f72/3l/vr/fX++v99f56f72/3l//717/B0Gg vrsAuAEA

--_004_BE2BFE91933D1B4089447C644860408068FB347Birsmsx503gerc or_--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 16.02.2011 01:42:34 von NeilBrown

On Tue, 15 Feb 2011 16:30:05 +0000 "Wojcik, Krzysztof"
wrote:

> > It might help to put a "WARN_ON(1)" in the place where it prints
> > "detected
> > capacity change ..." so we get a stack trace and can see how it got
> > there.
> > That might git a hint to what is looping.
> > Also a printk in md_open if it returns ERESTARTSYS would be
> > interesting.
>
> In attachment part of logs from kernel with WARN_ON(1) and value returned by md_open()
> (line preceded with "##### KW: err= x").
>
> I am trying to look for in new areas. I've run:
> Udevd --debug --dedug-traces
>
> Logs from udev and kernel in attachment.
> Maybe it will help to find solution...
> It seems to udev adds and removes device in loop...

Thanks for the extra logs.... it helps a bit, but I'm not a lot closer.

I've seen something a little bit like this which was fixed by adding

TEST!="md/array_state", GOTO="md_end"

just after

# container devices have a metadata version of e.g. 'external:ddf' and
# never leave state 'inactive'

in /lib/udev/rules.d/64-md-raid.rules

Could you try that??

It looks like the 'bdev' passed to md_open keeps changing, which it shouldn't.

If the above doesn't help, please add:

printk("bdev=%p, mddev=%p, disk=%p dev=%x\n", bdev, mddev, mddev->gendisk, bdev->bd_dev);

at the top of 'md_open', and see what it produces.

Thanks,
NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Single-drive RAID0

am 16.02.2011 17:57:06 von krzysztof.wojcik

--_002_BE2BFE91933D1B4089447C644860408069028F47irsmsx503gerc or_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Wednesday, February 16, 2011 1:43 AM
> To: Wojcik, Krzysztof
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Single-drive RAID0
>=20
> On Tue, 15 Feb 2011 16:30:05 +0000 "Wojcik, Krzysztof"
> wrote:
>=20
> > > It might help to put a "WARN_ON(1)" in the place where it prints
> > > "detected
> > > capacity change ..." so we get a stack trace and can see how it got
> > > there.
> > > That might git a hint to what is looping.
> > > Also a printk in md_open if it returns ERESTARTSYS would be
> > > interesting.
> >
> > In attachment part of logs from kernel with WARN_ON(1) and value
> returned by md_open()
> > (line preceded with "##### KW: err=3D x").
> >
> > I am trying to look for in new areas. I've run:
> > Udevd --debug --dedug-traces
> >
> > Logs from udev and kernel in attachment.
> > Maybe it will help to find solution...
> > It seems to udev adds and removes device in loop...
>=20
> Thanks for the extra logs.... it helps a bit, but I'm not a lot closer.
>=20
> I've seen something a little bit like this which was fixed by adding
>=20
> TEST!=3D"md/array_state", GOTO=3D"md_end"
>=20
> just after
>=20
> # container devices have a metadata version of e.g. 'external:ddf' and
> # never leave state 'inactive'
>=20
> in /lib/udev/rules.d/64-md-raid.rules
>=20
>=20
> Could you try that??

I tried. It not helps :(

>=20
> It looks like the 'bdev' passed to md_open keeps changing, which it
> shouldn't.
>=20
> If the above doesn't help, please add:
>=20
> printk("bdev=3D%p, mddev=3D%p, disk=3D%p dev=3D%x\n", bdev, mddev, mddev=
-
> >gendisk, bdev->bd_dev);
>=20
> at the top of 'md_open', and see what it produces.

I tried this also but I can't see any useful information that can make me s=
ome idea.
Could you look at logs in attachment?

Regards
Krzysztof

>=20
> Thanks,
> NeilBrown

--_002_BE2BFE91933D1B4089447C644860408069028F47irsmsx503gerc or_
Content-Type: application/x-compressed; name="kernel_log.tgz"
Content-Description: kernel_log.tgz
Content-Disposition: attachment; filename="kernel_log.tgz"; size=1830;
creation-date="Wed, 16 Feb 2011 16:53:43 GMT";
modification-date="Wed, 16 Feb 2011 16:51:48 GMT"
Content-Transfer-Encoding: base64

H4sIAOzHW00AA+2dXW/bNhSGc71fcYDdbGiTiJIlS8a6YSiwbhfrhqFAL4qC oEjKZq2vSpSd7Nfv
ULaDfsStrMRNvZ4XCCRR0qvDQ4rkE6VobsruirfrRhh12bW6aS+X6+qNNMvL pW5KnfO8ml/YK3s2
Xh4qmkz6LeqD7TRiXnTGWOhP8YiFwZnHptNwcgbeHZ45WF1rRQNw1lTVJ+v4 ufMnqt90CiwCFswm
8cwPYL7MRXrO/PicMQabLjADePVTtlXMvEwIGfz8Gn6BNF8qveJVrctH3pV3 6V1Nve/GWaZ+dotl
JMd7Ss0y1ntyrnRpm+udKwsCtPWDeKRvIDe+pSi0UcIKbiuembxG70mC1uE4 ZyUmk01iM1OadrGL
N0nRk0X+OFMZh5tw1SbImyzoKdpGejrKNvVEuIm1MPOF5Znocuvqry9dwGM8 fSWDQG1arBFr3tam
5F2ZV3KJxn7k2myUsaenQiS9scjRjmfK1V8ql1alx/UClWXJLq3tdbvLaijQ VI9rKqk9IXrPdwxZ
3/hqlKHnx0G6M7S64BLrj03V2lrYhTN3SWVDk3p+fv4KdKnANkJqiNlkGk+k SrM4StNoCq/xgoFW
hWJ+NAOlrZZWK5CiFtLYa5ALUc41ZE1VgAe2Qi/PC+KE+Tg7DDbvkweNth2W KFiJvNMz0E3zBAYP
JtsQawb10OZMceh6An3yY5zLmGIRm3iP0eq9E9PYS1KszmNQpl2+U554Kor7 cnd54mbHob3zXur8
fvxT4Ye+/4XiP39Hr0B2Fha60X2XutFAq5e//vP8j+fPZiAsZO1l6gYQnAFW F3KWRCH2MO2OMXLe
mn813/S43dAdez/8OPA5v4tGrQUG6eYB7DBbDbz7z0p1uW4hN+USm8uU2FZX 1ge3EpuEEYj2upS8
frvduaoacD+bo0IXsr7eHrg7It5oWa1gs39zl73CEqWrEqwtQDUFXxYtX+i8 1o07BONLLvJ5xVNj
oS0Vr2XBq7bt9wtzpZubo1a/3W1dNg2OAGWG8WN2ldvjQuYgOrvgTS3n7qau xD0w9Qprk3F8wZfa
gqy7rEELWZW43FwJa1b6prBfgdZucNmV1NUaiwReI2Rt+LYYCqxAhlOPbCpZ KRwv8E4MpapBFbyo
VB/pQgnuzkrcK8wHRUbZPlveTbkprc7B1gW3pnXbPjsm9li/Iytsanc2NVX7 vtnmaK10vcthv7Wm
wDSbF0//4mvVpxf6Z3AxrzfFKxxNq4a3XV1XDV6hG1O5uQ/aOdSyrZcNaBzG Pb29cW7xoqorVR9M
2lmLTds/Usw17yc3aCzGWmCI/Y67zu3kJoWuTRdGgfvpFtLwhcQ8qT5dssHO gosFk4HencLL+9u1
Uq5rBlCkUuDbA29SBZkoocbk67bFXmmUxlobPtclVkH2x/29bnG0K6zdQSGa lc6xo+BTsO+nN1sr
oJWt6aOx+O4XIt9t3fwKi3VRlQPfrb+NmoHPWIxDkayKwg2PQhXwQrg04rln u5f1Jf74F9FFEJ83
0n8E3wdDx8qnmG144SbC2bglbxIlmwXE5wakUfZBGGvZ2+MQVfI2r9Zuzucu HZVbV8RuuZ4kI80T
Jm4xL7s8d6uK0K0qxq0rj5sW308nahP5dsJ0y2u3DkzFSHAJvXALGVt0mWu3 DpZuHRyEY3EomU7f
xaGNJ8tcmwWBHGl639h2vAV7lshIb2JVOK+87UzjWj50SVXjFtdErUStRK1E rR9Qa0zU+oDUdwxq
jWWQBEStRK1ErUStJ0mtIVErUespUmuo9W2uLJ0SDBMMEwwTDBMMf80wnBAM PyBMHuUTrheziGCY
YJhgmGD4JGE42cEwLiux1gTDBMMEw980DPvRxzDcr4IJhgmGCYYJhu8HhgXB 8EcwjDQcE0wSTBJM
EkyeIEwmAX1ZJZg8RZgk6qNPoER9RH1EfUemvvTbob7Jw1HfvkcfVOdh8R/l X+Hue/QIat1ndd/U
uu85w6h1391ErUStRK13o9Z979YNtcZ3p9Z9z9hPrfvuuCc8G2Y/klqHmo+g 1q8hLQdQ68BwD6TW
wa6HfQIdansQDA81PYAGhzXSCA4Y2rkOgOGHqv6BMDzM83AYHup7OAwPcz4Q hgeaHgrDw2wPg+EH
fgkOguGBveAgGB7aswbD8DDDkTD8CWD5BAzL22B4P7vdAwwfFQzvDsNfFCZP HYaPEP8X/WUEwTzB
PME8wfx9wrzvsbv/PTPBPME8wfz/BuaH/z0zwTzBPME8wfwomFcE8+/D5CTz dRwRTBJMEkwSTJ4k
TEb0ZZhg8hRhkqiPPuES9RH1EfUdmfo0Ud8DUt8RPoFOFBPhVBK1ErUStRK1 niC1MkbUStR6itRK
n0AJhgmGCYYJhk8ThjOC4aPA5EP/L+YkEolEIpFIJBKJRCKRSCQSiUQikUgk EolEIpFI367+A81L
mnMAoAAA

--_002_BE2BFE91933D1B4089447C644860408069028F47irsmsx503gerc or_--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 17.02.2011 01:38:48 von NeilBrown

Re: Single-drive RAID0

am 21.02.2011 03:15:19 von NeilBrown

On Wed, 16 Feb 2011 16:57:06 +0000 "Wojcik, Krzysztof"
wrote:

> >
> > It looks like the 'bdev' passed to md_open keeps changing, which it
> > shouldn't.
> >
> > If the above doesn't help, please add:
> >
> > printk("bdev=%p, mddev=%p, disk=%p dev=%x\n", bdev, mddev, mddev-
> > >gendisk, bdev->bd_dev);
> >
> > at the top of 'md_open', and see what it produces.
>
> I tried this also but I can't see any useful information that can make me some idea.
> Could you look at logs in attachment?
>

I've made some progress.

The struct block_device is definitely getting freed and re-allocated.

This can happen if you

mknod /dev/.tmp b 9 0
open /dev/.tmp and do stuff, then close
rm /dev/.tmp

If you open something in /dev which stays there, e.g. /dev/md0, then as long
as the inode for /dev/md0 remains in the inode cache it will hold a reference
to the block_device and so the same one will get reused.
But when to 'rm /dev/.tmp', the inode gets flushed from the cache and the
reference of the block_device is dropped. If that was the only reference
then the block_device is discarded.

Each time a new block_device is created for a given block device, it will
re-do the partition scan which will mean that the partition devices get
deleted and recreated.

Maybe you are racing with this somehow and that is how the partition devices
appear to not be there - udev is removing and recreating them.

Something you could try would be to change fs/block_dev.c.
At about line 470 you should find:

static const struct super_operations bdev_sops = {
.statfs = simple_statfs,
.alloc_inode = bdev_alloc_inode,
.destroy_inode = bdev_destroy_inode,
.drop_inode = generic_delete_inode,
.evict_inode = bdev_evict_inode,
};

If you change the 'drop_inode' line to
.drop_inode = do_not_drop_inode,

and define a function:

static int do_not_drop_inode(struct inode *inode)
{
return 0;
}

That will cause the block_device to remain in a cache for a while after the
last reference is dropped.
That should make your symptoms go away.

I'm not sure that is the "right" fix, but it should confirm what I suspect
is happening.

If it does, then we can explore more...
Did you say that this works better on earlier kernels? If so, what is the
latest kernel that you have tried that you don't have this problem on?

Thanks,
NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Single-drive RAID0

am 21.02.2011 15:11:51 von krzysztof.wojcik

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Monday, February 21, 2011 3:15 AM
> To: Wojcik, Krzysztof
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Single-drive RAID0
>
> On Wed, 16 Feb 2011 16:57:06 +0000 "Wojcik, Krzysztof"
> wrote:
>
> > >
> > > It looks like the 'bdev' passed to md_open keeps changing, which it
> > > shouldn't.
> > >
> > > If the above doesn't help, please add:
> > >
> > > printk("bdev=%p, mddev=%p, disk=%p dev=%x\n", bdev, mddev, mddev-
> > > >gendisk, bdev->bd_dev);
> > >
> > > at the top of 'md_open', and see what it produces.
> >
> > I tried this also but I can't see any useful information that can
> make me some idea.
> > Could you look at logs in attachment?
> >
>
>
> I've made some progress.
>
>
> The struct block_device is definitely getting freed and re-allocated.
>
> This can happen if you
>
> mknod /dev/.tmp b 9 0
> open /dev/.tmp and do stuff, then close
> rm /dev/.tmp
>
>
> If you open something in /dev which stays there, e.g. /dev/md0, then as
> long
> as the inode for /dev/md0 remains in the inode cache it will hold a
> reference
> to the block_device and so the same one will get reused.
> But when to 'rm /dev/.tmp', the inode gets flushed from the cache and
> the
> reference of the block_device is dropped. If that was the only
> reference
> then the block_device is discarded.
>
> Each time a new block_device is created for a given block device, it
> will
> re-do the partition scan which will mean that the partition devices get
> deleted and recreated.
>
> Maybe you are racing with this somehow and that is how the partition
> devices
> appear to not be there - udev is removing and recreating them.
>
> Something you could try would be to change fs/block_dev.c.
> At about line 470 you should find:
>
> static const struct super_operations bdev_sops = {
> .statfs = simple_statfs,
> .alloc_inode = bdev_alloc_inode,
> .destroy_inode = bdev_destroy_inode,
> .drop_inode = generic_delete_inode,
> .evict_inode = bdev_evict_inode,
> };
>
> If you change the 'drop_inode' line to
> .drop_inode = do_not_drop_inode,
>
> and define a function:
>
>
> static int do_not_drop_inode(struct inode *inode)
> {
> return 0;
> }
>
> That will cause the block_device to remain in a cache for a while after
> the
> last reference is dropped.
> That should make your symptoms go away.
>
> I'm not sure that is the "right" fix, but it should confirm what I
> suspect
> is happening.

Hi,

I tested your proposal.
It resolve the problem.
What are your future plans?
Do you need to consult the patch with someone involved in the block devices code?
When can I expect final patch?

>
> If it does, then we can explore more...
> Did you say that this works better on earlier kernels? If so, what is
> the
> latest kernel that you have tried that you don't have this problem on?

I've tested on kernel 2.6.32 from RHEL6.0 and, if I remember correctly, 2.6.34- they work properly.

Regards
Krzysztof

>
> Thanks,
> NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 22.02.2011 01:50:11 von NeilBrown

On Mon, 21 Feb 2011 14:11:51 +0000 "Wojcik, Krzysztof"
wrote:

> Hi,
>
> I tested your proposal.
> It resolve the problem.

Thanks!

> What are your future plans?
> Do you need to consult the patch with someone involved in the block devices code?
> When can I expect final patch?

Here it is. As you can see it is quite different - I figured out what is
really going on..

>
> >
> > If it does, then we can explore more...
> > Did you say that this works better on earlier kernels? If so, what is
> > the
> > latest kernel that you have tried that you don't have this problem on?
>
> I've tested on kernel 2.6.32 from RHEL6.0 and, if I remember correctly, 2.6.34- they work properly.

That fits - I discovered that I broke it in 2.6.35.

Thanks,
NeilBrown

From b7fea734c7780ca80f58fb87a6c9f55aa83314d7 Mon Sep 17 00:00:00 2001
From: NeilBrown
Date: Tue, 22 Feb 2011 11:48:03 +1100
Subject: [PATCH] md: Fix - again - partition detection when array becomes active

Revert
b821eaa572fd737faaf6928ba046e571526c36c6
and
f3b99be19ded511a1bf05a148276239d9f13eefa

When I wrote the first of these I had a wrong idea about the
lifetime of 'struct block_device'. It can disappear at any time that
the block device is not open if it falls out of the inode cache.

So relying on the 'size' recorded with it to detect when the
device size has changed and so we need to revalidate, is wrong.

Rather, we really do need the 'changed' attribute stored directly in
the mddev and set/tested as appropriate.

Without this patch, a sequence of:
mknod / open / close / unlink

(which can cause a block_device to be created and then destroyed)
will result in a rescan of the partition table and consequence removal
and addition of partitions.
Several of these in a row can get udev racing to create and unlink and
other code can get confused.

With the patch, the rescan is only performed when needed and so there
are no races.

This is suitable for any stable kernel from 2.6.35.

Reported-by: "Wojcik, Krzysztof"
Signed-off-by: NeilBrown
Cc: stable@kernel.org
---
drivers/md/md.c | 22 +++++++++++++++++++++-
drivers/md/md.h | 2 ++
2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index 330addf..818313e 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4627,6 +4627,7 @@ static int do_md_run(mddev_t *mddev)
}
set_capacity(mddev->gendisk, mddev->array_sectors);
revalidate_disk(mddev->gendisk);
+ mddev->changed = 1;
kobject_uevent(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
out:
return err;
@@ -4715,6 +4716,7 @@ static void md_clean(mddev_t *mddev)
mddev->sync_speed_min = mddev->sync_speed_max = 0;
mddev->recovery = 0;
mddev->in_sync = 0;
+ mddev->changed = 0;
mddev->degraded = 0;
mddev->safemode = 0;
mddev->bitmap_info.offset = 0;
@@ -4830,6 +4832,7 @@ static int do_md_stop(mddev_t * mddev, int mode, int is_open)

set_capacity(disk, 0);
mutex_unlock(&mddev->open_mutex);
+ mddev->changed = 1;
revalidate_disk(disk);

if (mddev->ro)
@@ -6014,7 +6017,7 @@ static int md_open(struct block_device *bdev, fmode_t mode)
atomic_inc(&mddev->openers);
mutex_unlock(&mddev->open_mutex);

- check_disk_size_change(mddev->gendisk, bdev);
+ check_disk_change(bdev);
out:
return err;
}
@@ -6029,6 +6032,21 @@ static int md_release(struct gendisk *disk, fmode_t mode)

return 0;
}
+
+static int md_media_changed(struct gendisk *disk)
+{
+ mddev_t *mddev = disk->private_data;
+
+ return mddev->changed;
+}
+
+static int md_revalidate(struct gendisk *disk)
+{
+ mddev_t *mddev = disk->private_data;
+
+ mddev->changed = 0;
+ return 0;
+}
static const struct block_device_operations md_fops =
{
.owner = THIS_MODULE,
@@ -6039,6 +6057,8 @@ static const struct block_device_operations md_fops =
.compat_ioctl = md_compat_ioctl,
#endif
.getgeo = md_getgeo,
+ .media_changed = md_media_changed,
+ .revalidate_disk= md_revalidate,
};

static int md_thread(void * arg)
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 7e90b85..12215d4 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -274,6 +274,8 @@ struct mddev_s
atomic_t active; /* general refcount */
atomic_t openers; /* number of active opens */

+ int changed; /* True if we might need to
+ * reread partition info */
int degraded; /* whether md should consider
* adding a spare
*/
--
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: Single-drive RAID0

am 22.02.2011 12:50:11 von krzysztof.wojcik

> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Tuesday, February 22, 2011 1:50 AM
> To: Wojcik, Krzysztof
> Cc: linux-raid@vger.kernel.org
> Subject: Re: Single-drive RAID0
>
> On Mon, 21 Feb 2011 14:11:51 +0000 "Wojcik, Krzysztof"
> wrote:
>
> > Hi,
> >
> > I tested your proposal.
> > It resolve the problem.
>
> Thanks!
>
> > What are your future plans?
> > Do you need to consult the patch with someone involved in the block
> devices code?
> > When can I expect final patch?
>
> Here it is. As you can see it is quite different - I figured out what
> is
> really going on..
>
>
> >
> > >
> > > If it does, then we can explore more...
> > > Did you say that this works better on earlier kernels? If so, what
> is
> > > the
> > > latest kernel that you have tried that you don't have this problem
> on?
> >
> > I've tested on kernel 2.6.32 from RHEL6.0 and, if I remember
> correctly, 2.6.34- they work properly.
>
> That fits - I discovered that I broke it in 2.6.35.
>
> Thanks,
> NeilBrown

Hi,

I confirm. This patch resolve the problem.
I did tests on your current top of for-next branch and issue is not reproducible.
Thank for your cooperation! :-)

Regards
Krzysztof

>
> From b7fea734c7780ca80f58fb87a6c9f55aa83314d7 Mon Sep 17 00:00:00 2001
> From: NeilBrown
> Date: Tue, 22 Feb 2011 11:48:03 +1100
> Subject: [PATCH] md: Fix - again - partition detection when array
> becomes active
>
> Revert
> b821eaa572fd737faaf6928ba046e571526c36c6
> and
> f3b99be19ded511a1bf05a148276239d9f13eefa
>
> When I wrote the first of these I had a wrong idea about the
> lifetime of 'struct block_device'. It can disappear at any time that
> the block device is not open if it falls out of the inode cache.
>
> So relying on the 'size' recorded with it to detect when the
> device size has changed and so we need to revalidate, is wrong.
>
> Rather, we really do need the 'changed' attribute stored directly in
> the mddev and set/tested as appropriate.
>
> Without this patch, a sequence of:
> mknod / open / close / unlink
>
> (which can cause a block_device to be created and then destroyed)
> will result in a rescan of the partition table and consequence removal
> and addition of partitions.
> Several of these in a row can get udev racing to create and unlink and
> other code can get confused.
>
> With the patch, the rescan is only performed when needed and so there
> are no races.
>
> This is suitable for any stable kernel from 2.6.35.
>
> Reported-by: "Wojcik, Krzysztof"
> Signed-off-by: NeilBrown
> Cc: stable@kernel.org
> ---
> drivers/md/md.c | 22 +++++++++++++++++++++-
> drivers/md/md.h | 2 ++
> 2 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 330addf..818313e 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -4627,6 +4627,7 @@ static int do_md_run(mddev_t *mddev)
> }
> set_capacity(mddev->gendisk, mddev->array_sectors);
> revalidate_disk(mddev->gendisk);
> + mddev->changed = 1;
> kobject_uevent(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
> out:
> return err;
> @@ -4715,6 +4716,7 @@ static void md_clean(mddev_t *mddev)
> mddev->sync_speed_min = mddev->sync_speed_max = 0;
> mddev->recovery = 0;
> mddev->in_sync = 0;
> + mddev->changed = 0;
> mddev->degraded = 0;
> mddev->safemode = 0;
> mddev->bitmap_info.offset = 0;
> @@ -4830,6 +4832,7 @@ static int do_md_stop(mddev_t * mddev, int mode,
> int is_open)
>
> set_capacity(disk, 0);
> mutex_unlock(&mddev->open_mutex);
> + mddev->changed = 1;
> revalidate_disk(disk);
>
> if (mddev->ro)
> @@ -6014,7 +6017,7 @@ static int md_open(struct block_device *bdev,
> fmode_t mode)
> atomic_inc(&mddev->openers);
> mutex_unlock(&mddev->open_mutex);
>
> - check_disk_size_change(mddev->gendisk, bdev);
> + check_disk_change(bdev);
> out:
> return err;
> }
> @@ -6029,6 +6032,21 @@ static int md_release(struct gendisk *disk,
> fmode_t mode)
>
> return 0;
> }
> +
> +static int md_media_changed(struct gendisk *disk)
> +{
> + mddev_t *mddev = disk->private_data;
> +
> + return mddev->changed;
> +}
> +
> +static int md_revalidate(struct gendisk *disk)
> +{
> + mddev_t *mddev = disk->private_data;
> +
> + mddev->changed = 0;
> + return 0;
> +}
> static const struct block_device_operations md_fops =
> {
> .owner = THIS_MODULE,
> @@ -6039,6 +6057,8 @@ static const struct block_device_operations
> md_fops =
> .compat_ioctl = md_compat_ioctl,
> #endif
> .getgeo = md_getgeo,
> + .media_changed = md_media_changed,
> + .revalidate_disk= md_revalidate,
> };
>
> static int md_thread(void * arg)
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index 7e90b85..12215d4 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -274,6 +274,8 @@ struct mddev_s
> atomic_t active; /* general refcount */
> atomic_t openers; /* number of active opens */
>
> + int changed; /* True if we might need to
> + * reread partition info */
> int degraded; /* whether md should consider
> * adding a spare
> */
> --
> 1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 22.02.2011 17:42:14 von Jan Ceuleers

On 22/02/11 01:50, NeilBrown wrote:
> With the patch, the rescan is only performed when needed and so there
> are no races.

Neil,

If I've properly understood your commit message you are reducing the
frequency of the rescans, but they can still occur. I submit that this
merely reduces the probability but does not remove the possibility of
races with udev.

If my interpretation is correct, then is this something that should be
fixed (to remove the possibility of races altogether), or merely documented?

Thanks, Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Single-drive RAID0

am 23.02.2011 03:20:56 von NeilBrown

On Tue, 22 Feb 2011 17:42:14 +0100 Jan Ceuleers
wrote:

> On 22/02/11 01:50, NeilBrown wrote:
> > With the patch, the rescan is only performed when needed and so there
> > are no races.
>
> Neil,
>
> If I've properly understood your commit message you are reducing the
> frequency of the rescans, but they can still occur. I submit that this
> merely reduces the probability but does not remove the possibility of
> races with udev.
>
> If my interpretation is correct, then is this something that should be
> fixed (to remove the possibility of races altogether), or merely documented?
>
> Thanks, Jan

Thanks for reviewing the code!!

The patch should reduce the frequency of rescans to just those times when it
is actually needed.
i.e. when the array data first becomes available, and when it stops being
available.
So it will only happen as a direct result of an administrative action.

Previously it could happen at arbitrary times based on open /close/unlink
patterns.

So it isn't really "reducing the frequency" so much as "making it happen only
at well defined times, not arbitrary times".

So this does remove any possibility of races.

Thanks,
NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html