On Fri, 26 Sep 2014 14:50:08 +0200 Francis Moreau <francis.moro@xxxxxxxxx> wrote: > On 09/26/2014 02:21 PM, Francis Moreau wrote: > [...] > > > > >>>> mdadm --stop --scan <<< > > > > [ 89.975162] md_open(): md125 opened by mdadm [930] > > [ 89.975305] md_release(): md125 released by mdadm [930] > > [ 89.977434] md_open(): md125 opened by mdadm [932] > > [ 89.978813] md_open(): md125 opened by mdadm [930] > > [ 89.979365] md_release(): md125 released by mdadm [932] > > [ 89.979693] md_open(): md125 opened by systemd-udevd [931] > > [ 89.985790] md_release(): md125 released by systemd-udevd [931] > > [ 90.179911] md_release(): md125 released by mdadm [930] > > [ 90.180168] md_open(): md127 opened by mdadm [459] > > [ 90.180187] md_release(): md127 released by mdadm [459] > > [ 90.180199] md_open(): md126 opened by mdadm [459] > > [ 90.180205] md_release(): md126 released by mdadm [459] > > [ 90.180556] md_open(): md126 opened by mdadm [930] > > [ 90.180653] md_release(): md126 released by mdadm [930] > > [ 90.180690] md_open(): md126 opened by mdadm [930] > > [ 90.180758] md_open(): mdX opened by mdadm [459] > > What is this 'mdX' device that mdadm operates on ? > > It also doesn't have a counterpart release() call. 'mdX' is the name used if mddev->gendisk is NULL. In that case, md_open() will return an error (ERESTARTSYS). As the 'open' failed, we wouldn't expect a matching close/release. NeilBrown > > > > [ 90.180995] md_open(): md125 opened by mdadm [459] > > [ 90.181056] md_release(): md125 released by mdadm [459] > > [ 90.182717] md_open(): md127 opened by mdadm [459] > > [ 90.182725] md_release(): md127 released by mdadm [459] > > [ 90.182732] md_open(): md126 opened by mdadm [459] > > [ 90.182761] md_release(): md126 released by mdadm [459] > > [ 90.182770] md_open(): md125 opened by mdadm [459] > > [ 90.182775] md_release(): md125 released by mdadm [459] > > [ 90.182940] md_release(): md126 released by mdadm [930] > > [ 90.183167] md_open(): md127 opened by mdadm [930] > > [ 90.183257] md_release(): md127 released by mdadm [930] > > [ 90.183288] md_open(): md127 opened by mdadm [930] > > [ 90.183461] md_open(): md127 opened by mdadm [459] > > [ 90.183488] md_release(): md127 released by mdadm [459] > > [ 90.183499] md_open(): md125 opened by mdadm [459] > > [ 90.183505] md_release(): md125 released by mdadm [459] > > [ 90.183686] md_release(): md127 released by mdadm [930] > > > > > >> Probably there is a 'change' event happening just before the 'remove' event, > >> and udev runs "mdadm" on the 'change' event, and that ends up happening after > >> the device has been removed. > >> > >> Is this really a problem? Can't you just ignore it and pretend it isn't > >> there? > > > > Well, if you list the block devices that the kernel detected in order to > > operate on them, it could. I don't know exactly what would be the result > > to use it but it could confuse some tools. > > > > Is there a way to check that the 'ghost' device has been removed by > > poking sysfs ? > > > > Thanks > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
pgplwYQBAnAic.pgp
Description: OpenPGP digital signature
