NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Corrupted file system or WAPBL problem with 5.0.1?

Frank Wille wrote:
Jean-Yves Migeon wrote:

cygnus# ll -a
ls: imap/INBOX: No such file or directory
total 12
drwx------  3 info  users  512 Oct  2 21:23 .
drwxr-xr-x  3 info  users  512 Feb  7  2009 ..
drwx------  3 info  users  512 Feb  7  2009 .imap
-rw-------  1 info  users    0 Feb  7  2009 inbox

No such file or directory? A ghost file? Perhaps the file system is

Does it get listed by shell expansion when you do ll -d imap/* ?

cygnus# ll -d imap/*
ls: imap/*: No such file or directory

But when I type "ll -d im" in bash and press TAB, the path expands to
"imap/INBOX", although it doesn't exist. Strange.

IMHO, I don't see how WAPBL could do that. I would rather look for
faulty hardware, with silent on-disk/write data corruption. $ atactl
<device>  smart status.

Ohoh... that doesn't look good:

cygnus# atactl wd0 smart status
SMART supported, SMART enabled
id value thresh crit collect reliability description                    raw
   1  57    6     yes online  positive    Raw read error rate
   3  97    0     yes online  positive    Spin-up time                   0
   4 100   20     no  online  positive    Start/stop count               0
   5 100   36     yes online  positive    Reallocated sector count       0
   7  84   30     yes online  positive    Seek error rate

195  57    0     no  online  positive    Hardware ECC Recovered
Millions of errors. I should probably replace the disk... :|

Actually not if that's a Seagate drive. Those are vendor specific fields and every manufacturer does it differently. On Seagate drives the raw values for those fields is always high. To give you an example here is the SMART output for those two fields from one of my perfectly working drives: 195 64 0 no online positive Hardware ECC Recovered 145771605 7 80 30 yes online positive Seek error rate 112466543 This is from a seagate drive in my amd64 5.0 STABLE system and is working perfectly. The odd behavior of these fields was recently discussed on the FreeBSD stable mailing list which I read at work. Here's a link to the thread on google.


Home | Main Index | Thread Index | Old Index