Your message dated Sun, 25 Sep 2011 15:45:43 -0400
with message-id <[email protected]>
and subject line Re: Bug#636290: linux-image-2.6.32-5-amd64: serious ext4
filesystem corruption even after fsck
has caused the Debian Bug report #636290,
regarding linux-image-2.6.32-5-amd64: serious ext4 filesystem corruption even
after fsck
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
636290: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636290
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.32-5
Severity: important
running 2.6.32-5-amd64, after running fsck on a corrupted ext4
filesystem which is an LVM partition on top of a RAID1 mirror with 3
drives and is 1tb in size, there are *still* errors after the fsck,
as detected by running fsck a 2nd time.
i'd say this is fairly serious, and am not going to hang about: will
be moving this data onto ext3 as quickly as possible.
-- Package-specific info:
-- System Information:
Debian Release: squeeze/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.32-trunk-amd64 depends on:
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii initramfs-tools [linux-initr 0.99 tools for generating an initramfs
ii module-init-tools 3.12~pre1-1 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.32-trunk-amd64 recommends:
ii firmware-linux-free 3 Binary firmware for various driver
Versions of packages linux-image-2.6.32-trunk-amd64 suggests:
pn grub | lilo <none> (no description available)
pn linux-doc-2.6.32 <none> (no description available)
Versions of packages linux-image-2.6.32-trunk-amd64 is related to:
pn firmware-bnx2 <none> (no description available)
pn firmware-bnx2x <none> (no description available)
pn firmware-ipw2x00 <none> (no description available)
pn firmware-ivtv <none> (no description available)
pn firmware-iwlwifi <none> (no description available)
pn firmware-linux <none> (no description available)
ii firmware-linux-nonfree 0.32 Binary firmware for various driver
pn firmware-qlogic <none> (no description available)
pn firmware-ralink <none> (no description available)
-- debconf information excluded
--- End Message ---
--- Begin Message ---
tags 636290 +unreproducible
thanks
OK, thanks, closing as unreproducible.
- Ted
On Sun, Sep 25, 2011 at 04:05:49PM +0100, Luke Kenneth Casson Leighton wrote:
> >
> > Otherwise, I propose to close this bug report with a tag of
> > "unreproducible".
>
> yep - apologies, i meant to provide further info: it turns out that
> the western digital 1.5gb "green" drives are "unfit for purpose". the
> policy in western digital is to take drives off the production line
> and test them. if they pass, they're labelled as "black". if they
> fail, they're ramped down in speed a bit, tested again and labelled as
> "green".
>
> in this case however that 2nd batch of testing - by the manufacturer
> - was completely inadequate. even just attempting to re-sync the RAID
> was enough to push these drives - all four of them - over the edge
> into "intermittent unreliability".
>
> so by the time the sync had finished, there would be 170,000 RAID1
> mismatch count errors. by the time a raid _sync_ had finished, there
> would be 170,000 RAID1 mis-matches.
>
> good one, huh? so, perhaps unsurprising that there was... uh... a
> bit of a problem with the file system.
>
> l.
>
>
--- End Message ---
