Re: Meaning of "Used Dev Space" in "mdadm --detail" output for a 6 disk RAID10 array

On Tue, 10 Jan 2012 14:11:34 -0500 Bobby Kent [off-list ref]
wrote:

On Monday, January 09, 2012 22:09 -0500 On Behalf Of NeilBrown <
linux-raid-owner@vger.kernel.org> wrote:

quoted

On Mon, 09 Jan 2012 21:20:39 -0500 Bobby Kent

[off-list ref]

quoted

wrote:

quoted

 Is Used Dev Space a measure of the capacity on each member device used

by the array? 

quoted

Yes.

NeilBrown

Hey NeilBrown,

Many thanks for clearing that up. 

On the metadata question the mdadm man page at
http://linux.die.net/man/8/mdadm implies that the driving criteria for
upgrading from 0.90 is use of HDDs with > 2 TB capacity or > 28 HDDs within
a raid device, neither of which are in my current plans, though I imagine at
some point I'll purchase larger HDDs.  Are there any other factors I should
consider (e.g. kernel version compatibility)?

Some newer features - such as bad-block lists - are only supported for 1.x
metadata.

Certainly use 1.x for new arrays, but I wouldn't bother converting old arrays
unless you wanted to convert to large devices (and current kernel/mdadm can
handle 4TB with 0.90 - the 2TB limit was a bug).

In my previous mail I might have been a little clearer in describing the
hangs/lock ups I was experiencing, as there may have been an unintended
implication that md was somehow at fault.  What I observed was that after
several hours of uptime the system would hang/lock up, nothing was written
to syslog, the desktop froze (mouse unresponsive, clock did not advance,
etc), network unresponsive (could not get a ping response), HDD access LED
was on.  Hitting the reset button appeared to be my only option to get back
to a working system (on one occasion my machine was left in this state for
90+ mins).  I am typically unwilling to hit the reset button, I probably did
it more times last week (3 times after the "downgrading" to 3.0.6 kernel)
than in the prior 18 months.

I would try alt-sysrq-P or alt-sysrq-T to try to find out what is hanging.

It was the LED that lead me to wonder about a resync following a hard stop,
and after discovering resyncs had not completed I left my machine booted to
the login prompt (rather than logged into in KDE) one night.  To further
muddy the waters the lock ups occurred while I was making some configuration
changes in order to implement real time processing for audio software.  I've
backed these out prior to the "login prompt boot", and, on balance, I
suspect these may have been the ultimate cause.  Speculation of course,
though without evidence to the contrary, I typically assume issues are of my
own creation rather than the fault of otherwise perfectly stable software
and hardware.  The original question about mdadm output was more a sanity
check that the arrays were configured consistent with expectations.

I'm thinking of setting both LOCKUP_DETECTOR and DETECT_HUNG_TASK in future
kernel builds, hopefully these will provide additional information should
something similar happen in the future.  Are there any other recommended
kernel settings I should implement?

Nothing springs to mind.

NeilBrown

Thanks again,

Bobby

--
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