On Wed, 26 Sep 2012 13:33:49 -0600 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Sep 26, 2012, at 6:17 AM, Günther J. Niederwimmer wrote: > >> > >> dirty state. > > > > OK, I run the Intel Tool in windows two times with the last Tool I found. > > > > The Tool don't found any Problem (?) and don't repair, but mdadm…. > > I'm going to trim this down: > > > > > /dev/sda: > > [Volume0]: > > UUID : ec120401:b6ed52e6:3814fac4:48fcf4fc > > Map State : normal > > Dirty State : clean > > > > > > /dev/sdb: > > [Volume0]: > > UUID : ec120401:b6ed52e6:3814fac4:48fcf4fc > > Map State : normal > > Dirty State : dirty > > °°°°°°° > > I don't understand this UI. Are there two Volume0's? > > I can see how the dirty state would apply independently among physical devices /dev/sda and /dev/sdb. But the virtual device, the array volume, "Volume0" seems like it would have only one instance. So I don't understand how it can be clean in one case and dirty in another. > It just means that when looking at the metadata on /dev/sda, we see it marked 'clean', and when looking at the metadata on /dev/sdb, we see that it is marked 'dirty'. Possibly something wrote to Volume0 between these two events, so the volume got marked 'dirty' so the write could happen. Wait a few seconds and it should get marked 'clean' again. Or possibly there is a bug somewhere. I would open two windows. In one run watch -d mdadm -E /dev/sda and in the other run watch -d mdadm -E /dev/sdb then access the array, or maybe leave it alone, and see how the metadata changes with time. NeilBrown
Attachment:
signature.asc
Description: PGP signature
