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

Re: Disk heads won't park



Hi

I was in the process of setting up smartd when i noticed the head
noise (although it's not the first time i've noticed it). smartd is
enabled now. I don't even have X installed yet (i'm trying to keep the
system minimal while i figure out all the issues), so KDE and other
DE's is out of the equation.

I've ran smartctl -a on all 4 drives[1] (sda+sdc output immediately,
sdb always takes longer, sdd in between with a distinctive sound - so
not the drive that's making noise), then again 5m later and again 12m
after that.

There were no changes in Start_Stop_Count or Load_Cycle_Count. The
value that stands out (to me) is Head_Flying_Hours, which means "Time
spent during the positioning of the drive head". I was expecting
something like that for sdb, but not for sda+sdc. sdd doesn't have
that field at all. While for sda+sdc the RAW value is human-readable,
the same can't be said for sdb. The difference doesn't seem to be in
seconds. The only drive that has differences in WORST/THRESH is sdd,
which makes sense since it's the oldest.


On Mon, Feb 17, 2014 at 9:43 PM, Igor Cicimov <icicimov@gmail.com> wrote:
> In /etc/lvm/lvm.conf, did you exclude /dev/sdb1 in the devices section
> filter so it doesn't get scanned by lvm?

Yup, from:

filter = [ "a/.*/" ]

to:

filter = [ "r|/dev/sdb1|",
"r|/dev/disk/by-id/ata-ST31000528AS_5VP5KAH7-part1|",
"r|/dev/disk/by-id/scsi-SATA_ST31000528AS_5VP5KAH7-part1|",
"r|/dev/disk/by-id/wwn-0x5000c50027db4afd-part1|",
"r|/dev/disk/by-path/pci-0000:00:0e.0-scsi-1:0:0:0-part1|", "a/.*/" ]

And ran vgscan.

All these are simlinks to /dev/sdb1. Not doing this just makes GRUB
complain about invalid LVM headers or similar, but it does show the
boot menu and proceeds. I blame this on me screwing around with RAID
and LVM, maybe the boot process is looking at the wrong MBR.

Actually... shortly after this data-loss mess i reinstalled and
upgraded sdb's firmware from CC38 to CC49 to match that of sda and
sdc. Rebooted, GRUB couldn't boot, even though back then /boot was not
separate from /, / was in LVM/RAID and was booting without issues
before. But that was a few weeks ago and this is not the first time i
hear continuous head noise (i.e. before the firmware upgrade).

After a few hours struggling with grub's normal and rescue prompts and
abusing grub-install i went and reinstalled, this time removing /boot
from LVM/RAID as it is not configured. I believe GRUB hickups now
because of some leftovers from then - is there any way i can clear
MBRs and whatever might be used by grub during an installation?

In the meantime i halted and unplugged the system for a few minutes.
It's now paused at the BIOS right after it detects the drives. Right
after it powers on the heads start flying around and it's still doing
it. I had lost data on sdb a while back (before the firmware upgrade),
but back then i blamed it on me not having the /stuff partition (then
with 300GB - recovered) being fsck-ed in /fstab and maybe some
weirdness between ext4 (barriers?) and wheezy's Xen (not installed at
the moment). Even though smartctl -t long didn't find anything, i'm
beginning to blame it on the hardware, but i'd like to be really sure.
Except for head noise (and that partition corruption), the  drive
seems fine and it's not that old. Most of the times there is no noise,
but sometimes, like now, it just won't stop. The Maxtor's older and
it's still running fine and it's not like this system is I/O
intensive; heck for the last few months it's been mainly my testbed
for Xen, LVM and RAID with little or no services.

Guess in the end i'll remove both sdb and sdd and see how stable the
system is, then add them back one by one with a few weeks in between.
While i'm at it i might as well use jessie, Xen's more recent. Is
there an ISO that's not a nightly build? Any easier way other than
installing stable dist-upgrading to testing?

Still, i'd like to be positive that this is indeed a firmware/hardware issue.

Sorry for the -vvv messages :|

Cheers,
Nuno


Reply to: