1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#263974: raidtools2: Spurious "some disks seem to have failed" messa

    From Mario 'BitKoenig' Holbe@1:229/2 to Zygo Blaxell on Fri Aug 13 13:30:14 2004
    From: [email protected]

    On Fri, Aug 06, 2004 at 11:10:22AM -0400, Zygo Blaxell wrote:
    I am now receiving emails like these from all of my systems that have
    117880960 blocks [3/2] [UU_]
    The trouble is, there are no broken disks in the array, it just has 2

    Same here.
    I'm running a bunch of degraded arrays and the daily cron mail is
    just a pain in the neck.

    Previously-working-but-now-failed disks have the string "(F)" appended
    in the mdstat output, but I'm not sure if these disappear after a reboot.

    No, they only disappear, if you remove the failed device from the
    array. As long as you don't do so, the failed device remains in
    the array. Even during reboot and reconstruction.

    Perhaps it would help to just make it configure-able, if degraded
    arrays should be noted.


    regards,
    Mario
    --
    () Ascii Ribbon Campaign
    /\ Support plain text e-mail


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Zygo Blaxell@1:229/2 to All on Fri Aug 6 17:30:11 2004
    From: [email protected]

    Package: raidtools2
    Version: 1.00.3-9
    Severity: normal

    I am now receiving emails like these from all of my systems that have raidtools2 1.00.3-9 installed:

    /etc/cron.daily/raidtools2:
    WARNING: Some disk(s) in your RAID array(s) seems to have failed!
    Below is the content of /proc/mdstat:

    Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6]
    md0 : active raid1 hda2[0] hdc2[1]
    117880960 blocks [3/2] [UU_]

    unused devices: <none>

    The trouble is, there are no broken disks in the array, it just has 2
    active disks out of 3 available slots. The empty slots in the RAID
    arrays exist so that a third disk can be temporarily added to the array
    from time to time to capture a snapshot of the filesystem on an external
    disk (e.g. on a hotpluggable firewire device) without interfering too
    much with the operation of the system.

    I'm not sure what a valid resolution of this problem would be, other
    than maybe comparing the mdstat content to previously observed mdstat
    content, or comparing it to a config file. My own needs would be served
    by getting an email whenever the mdstat file changes: I wouldn't mind the false alarms from the occasional resync status message, as I'd probably
    like to know each time the machine was in a state where it needed to do
    a resync in any case. The email that would be generated when the array
    is first created would serve as a useful test of the raidtools script
    and email system. I can also live with one false positive on a 2.4 to
    2.6 transition. On the other hand, the output of something like 'lsraid'
    might be a better basis for comparison.

    Previously-working-but-now-failed disks have the string "(F)" appended
    in the mdstat output, but I'm not sure if these disappear after a reboot.

    -- System Information:
    Debian Release: 3.1
    APT prefers testing
    APT policy: (102, 'testing'), (101, 'unstable')
    Architecture: i386 (i686)
    Kernel: Linux 2.4.24-zb-586-smp
    Locale: LANG=C, LC_CTYPE=C

    Versions of packages raidtools2 depends on:
    ii debconf 1.4.30 Debian configuration management sy ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii makedev 2.3.1-70 Creates device files in /dev

    -- debconf information excluded


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)