[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
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
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
195 64 0 no online positive Hardware ECC Recovered
7 80 30 yes online positive Seek error rate
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.
195 57 0 no online positive Hardware ECC Recovered
Millions of errors. I should probably replace the disk... :|
Main Index |
Thread Index |