All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dexter Filmore <Dexter.Filmore@gmx.de>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: when is a disk "non-fresh"?
Date: Thu, 7 Feb 2008 23:16:20 +0100	[thread overview]
Message-ID: <200802072316.20907.Dexter.Filmore@gmx.de> (raw)
In-Reply-To: <18343.50072.164266.861934@notabene.brown>

On Tuesday 05 February 2008 03:02:00 Neil Brown wrote:
> On Monday February 4, Dexter.Filmore@gmx.de wrote:
> > Seems the other topic wasn't quite clear...
>
> not necessarily.  sometimes it helps to repeat your question.  there
> is a lot of noise on the internet and somethings important things get
> missed... :-)
>
> > Occasionally a disk is kicked for being "non-fresh" - what does this mean
> > and what causes it?
>
> The 'event' count is too small.
> Every event that happens on an array causes the event count to be
> incremented.

An 'event' here is any atomic action? Like "write byte there" or "calc XOR"?


> If the event counts on different devices differ by more than 1, then
> the smaller number is 'non-fresh'.
>
> You need to look to the kernel logs of when the array was previously
> shut down to figure out why it is now non-fresh.

The kernel logs show absolutely nothing. Log's fine, next time I boot up, one 
disk is kicked, I got no clue why, badblocks is fine, smartctl is fine, selft 
test fine, dmesg and /var/log/messages show nothing apart from that news that 
the disk was kicked and mdadm -E doesn't say anything suspicious either.

Question: what events occured on the 3 other disks that didn't occur on the 
last? It only happens after reboots, not while the machine is up so the 
closest assumption is that the array is not properly shut down somehow during 
system shutdown - only I wouldn't know why.
Box is Slackware 11.0, 11 doesn't come with raid script of its own so I hacked 
them into the boot scripts myself and carefully watched that everything 
accessing the array is down before mdadm --stop --scan is issued.
No NFS, no Samba, no other funny daemons, disks are synced and so on.

I could write some failsafe inot it by checking if the event count is the same 
on all disks before --stop, but even if it wasn't, I really wouldn't know 
what to do about it.

(btw mdadm -E gives me:     Events : 0.1149316 - what's with the 0. ?)

Dex



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+)@ s-:+ a- C++++ UL++ P+>++ L+++>++++ E-- W++ N o? K-
w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ 
b++(+++) DI+++ D- G++ e* h>++ r* y?
------END GEEK CODE BLOCK------

http://www.vorratsdatenspeicherung.de

  reply	other threads:[~2008-02-07 22:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03  2:54 non-fresh: what? Dexter Filmore
2008-02-04 22:05 ` when is a disk "non-fresh"? Dexter Filmore
2008-02-05  2:02   ` Neil Brown
2008-02-07 22:16     ` Dexter Filmore [this message]
2008-02-07 23:22       ` Neil Brown
2008-02-08  9:32         ` Dexter Filmore
2008-02-10 10:36           ` David Greaves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802072316.20907.Dexter.Filmore@gmx.de \
    --to=dexter.filmore@gmx.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.