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 <icici...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadqa9uyavukkuvhqgnoxz6ax8-cvgrgsykyouyuzfks0hyw...@mail.gmail.com