Re: Recurring disk activity
On Thu, Jun 25, 2015 at 06:59:08PM -0600, Bob Proulx wrote: # hdparm -B255 /dev/sda I had disabled this when I wrote the OP, but had not set it in /etc/hdparm.conf. Today I did that and the Load_Cycle_Count seems steadied at 3781, though it is still under observation. Good deal! Thanks a lot for insightful help and the links to articles! I'll be using the new laptop now without constant fear of slow death of the hard drive! I am not too worried about the power management as the laptop is for indoor use. Will retain above settings for the long run. Mayuresh. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150626070813.GA20003@odin
Re: Recurring disk activity
Mayuresh wrote: On Tue, Jun 23, 2015 at 01:27:10PM -0600, Bob Proulx wrote: # hdparm -B255 /dev/sda I had disabled this when I wrote the OP, but had not set it in /etc/hdparm.conf. Today I did that and the Load_Cycle_Count seems steadied at 3781, though it is still under observation. Good deal! When I wrote the OP I got an impression that -B255 isn't helping, because I wasn't aware of Load_Cycle_Count and I measured the disk activity by the following command: iotop -ob --delay .1 This still continues to show kworker doing some activity: 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.87 % [kworker/1:2] ... What to attribute this disk activity to? I have tried checking using lsof whether any files are changing that fast (such as syslog) but that is not the case. That looks like a fairly low level of activity. It can be hard to chase down everything that writes to the disk. This is a topic that you can read more about in the laptop lists. For example laptop-mode tries to hold off disk writes so as save battery by avoiding disk spinups. Researching documentation there would be useful. Here is an old Linux Journal article no it. http://www.linuxjournal.com/article/7539 There is a kernel interface to debug blocks written to disk. Here is a nice quick summary of the feature. http://www.unixdaemon.net/linux/proc-block-dump.html And more detail here: http://samwel.tk/laptop_mode/faq WARNING! You want to make sure your debug logging doesn't cause more disk activity which causes more logging which causes more disk activity and so on in a vicious feedback loop. The faq article above describes this in more detail. But here is a snippet from the proc-block-dump article to show the capabilities. Mar 14 19:16:44 localhost kernel: sshd(2659): dirtied inode 388836 (sshd) on sda1 Mar 14 19:16:44 localhost kernel: sshd(2659): dirtied inode 533395 (libwrap.so.0) on sda1 Mar 14 19:17:23 localhost kernel: cat(2672): dirtied inode 05 (.bash_history) on sda1 Mar 14 19:17:46 localhost kernel: kjournald(913): WRITE block 14016 on sda1 Mar 14 19:17:48 localhost kernel: pdflush(104): WRITE block 12487672 on sda1 Note that I haven't used this since those articles were written. I will assume that things are still similar now ten years later. But it has been ten years. I expect some things to be different. But by investigating those features you should be able to tell exactly what is hitting your disk. Bob signature.asc Description: Digital signature
Re: Recurring disk activity
On Tue, Jun 23, 2015 at 01:27:10PM -0600, Bob Proulx wrote: # hdparm -B255 /dev/sda I had disabled this when I wrote the OP, but had not set it in /etc/hdparm.conf. Today I did that and the Load_Cycle_Count seems steadied at 3781, though it is still under observation. When I wrote the OP I got an impression that -B255 isn't helping, because I wasn't aware of Load_Cycle_Count and I measured the disk activity by the following command: iotop -ob --delay .1 This still continues to show kworker doing some activity: 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.87 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.73 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.70 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.72 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.72 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.69 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.84 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.86 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.86 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.89 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.92 % [kworker/1:2] 103 be/4 root0.00 B/s0.00 B/s 0.00 % 0.84 % [kworker/1:2] What to attribute this disk activity to? I have tried checking using lsof whether any files are changing that fast (such as syslog) but that is not the case. Mayuresh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150624144053.GA10018@odin
Re: Recurring disk activity
On Mon, Jun 22, 2015 at 02:16:49PM -0600, Bob Proulx wrote: Is your Load_Cycle_Count continuously increasing? Doesn't look like. It was 3634 when I started watching and over last few minutes it changed only to 3635. That still seems like a rather high load_cycle_count. And if it is increasing every minute then I would investigate the issue further. What does this say? What does it indicate. It was 3755 when I started the system today and growing over a few minutes. hdparm -B /dev/sda /dev/sda: APM_level = 128 Is your laptop something that is mostly off but only sometimes on? Or It is static and mostly off. I can keep it on if needed. It doesn't have to move around. But isn't there something I can run one time to know the issue. If I can at least ascertain that the issue is with the drive, I can try and get it replaced in warranty. I am unsure since the laptop came with FreeDOS and when booting on FreeDOS there is no disk noise. So difficult to convince the retailer that there is an issue with the drive. Mayuresh. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150623150903.GA28945@odin
Re: Recurring disk activity
On Tue, Jun 23, 2015 at 08:39:03PM +0530, Mayuresh wrote: What does it indicate. It was 3755 when I started the system today and growing over a few minutes. I got what it indicates. It's scary... I noticed utilities to fix this problem in the wd drives. I checked my drive, it is: ata1.00: ATA-9: HGST HTS545050A7E680, GR2OA350, max UDMA/133 So, not sure whether there exists a utility to fix its head parking problem. Also not clear, why I don't get that noise when booting to FreeDOS. Mayuresh. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150623155844.GA14633@odin
Re: Recurring disk activity
On Tue, Jun 23, 2015 at 04:00:52PM +, Curt wrote: Your URL doesn't specify the brand/model of hard drive in your laptop. It just says 500 GB SATA 5400 rpm. dmesg reports this. I searched, but could not even find whether this has head parking problem and if so why the disk is quiet on FreeDOS. ata1.00: ATA-9: HGST HTS545050A7E680, GR2OA350, max UDMA/133 Mayuresh. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150623160334.GA28733@odin
Re: Recurring disk activity
On 2015-06-23, Mayuresh mayur...@acm.org wrote: On Tue, Jun 23, 2015 at 04:00:52PM +, Curt wrote: Your URL doesn't specify the brand/model of hard drive in your laptop. It just says 500 GB SATA 5400 rpm. dmesg reports this. I searched, but could not even find whether this has head parking problem and if so why the disk is quiet on FreeDOS. ata1.00: ATA-9: HGST HTS545050A7E680, GR2OA350, max UDMA/133 Mayuresh. Hitachi HGST. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnmoj2ic.1t2.cu...@einstein.electron.org
Re: Recurring disk activity
On 2015-06-20, Mayuresh mayur...@acm.org wrote: Laptop spec: http://support.hp.com/us-en/product/HP-15-r200-Notebook-PC-series/7486447/model/7748035/document/c04576750/ I had a head parking/unparking/Load_Cycle_Count problem on my desktop machine (Western Digital Green Drive--known issue in linux) and decided to disable the infamous idle3 timer entirely (caveat emptor). http://idle3-tools.sourceforge.net/ Your URL doesn't specify the brand/model of hard drive in your laptop. It just says 500 GB SATA 5400 rpm. Here's some ideas (some of which it looks like you've already tried): Maybe you know all this already: http://www.thinkwiki.org/wiki/Problem_with_hard_drive_clicking -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnmoj0lk.1t2.cu...@einstein.electron.org
Re: Recurring disk activity
Mayuresh wrote:
Bob Proulx wrote:
hdparm -B /dev/sda
/dev/sda:
APM_level = 128
man hdparm
-B Get/set Advanced Power Management feature, if the drive supports
it. A low value means aggressive power management and a high
value means better performance. Possible settings range from
values 1 through 127 (which permit spin-down), and values 128
through 254 (which do not permit spin-down). The highest degree
of power management is attained with a setting of 1, and the
highest I/O performance with a setting of 254. A value of 255
tells hdparm to disable Advanced Power Management altogether on
the drive (not all drives support disabling it, but most do).
I admit I am not sure but I think 128 as above won't force a spindown
and therefore doesn't seem to be the link for head parking. I look at
a few of my systems and they either have 128 or off depending upon the
drive. The ones with 128 have a moderate load cycle count in the low
hundreds. Therefore I would normally say that is okay.
But you said you saw it increasing on your system and it was in the
thousands. Therefore I would be inclined to suggest that it should be
disabled on your system.
# hdparm -B255 /dev/sda
Or if you like turn power management to the lowest level. Since it is
a laptop I would tend to use the 254 conservative figure.
# hdparm -B254 /dev/sda
If I can at least ascertain that the issue is with the drive, I can try
and get it replaced in warranty. I am unsure since the laptop came with
FreeDOS and when booting on FreeDOS there is no disk noise. So difficult
to convince the retailer that there is an issue with the drive.
You only reported a load_cycle_count in the thousands. Before this
problem was well known I had drives in the hundreds of thousands.
Some of those are still running fine. I wouldn't worry about it. But
I would prevent it from getting worse.
Note one crazy thing. I have an SSD that reports a load cycle count
in the 335738 range. Obviously there isn't any head to park and it is
simply reporting the number of times it would have parked if it were a
spinning hard drive with a head. For anyone who looks at an SSD and
depending upon the firmware might get spooked it isn't a worry there.
What does it indicate. It was 3755 when I started the system today and
growing over a few minutes.
I got what it indicates. It's scary...
At 3755 I wouldn't worry. Drives are rated in the hundreds of
thousands. Your drive is still young by the metrics.
I noticed utilities to fix this problem in the wd drives. I checked my
drive, it is:
ata1.00: ATA-9: HGST HTS545050A7E680, GR2OA350, max UDMA/133
So, not sure whether there exists a utility to fix its head parking
problem. Also not clear, why I don't get that noise when booting to
FreeDOS.
It depends upon many things. Configuration and use patterns. It may
not be a problem under FreeDOS. In any case for this particular issue
it is easy to fix.
You already have hdparm installed. There are multiple ways to
configure hdparm to set the -B option automatically. The config file
/etc/default/hdparm is probably best for you. This configuration will
set it for you at boot time.
harddisks=/dev/sda
hdparm_opts=-B254
As long as I am talking I will mention that I have a couple of drives
that require this. But I didn't want to set it for all drives.
Therefore for me on my servers where I have automated configuration to
detect and configure these things I set up the following section in
the /etc/hdparm.conf file.
/dev/disk/by-id/scsi-SATA_ST2000DM001-1CH_S1E14TKT {
apm = 254
}
With that in place hdparm sets it only for that one specific disk
drive and serial number combination. It doesn't get set for other
disks that don't need it. Plus since I have dynamic system
configuration if I move the drive from one system to another my config
scripts move the configuration to follow the drive. That is a whole
different topic but basically something like puppet, chef, and so forth.
It is static and mostly off. I can keep it on if needed. It doesn't have
to move around. But isn't there something I can run one time to know the
issue.
I would be inclined to write a short script that is run from the
cron.daily run from anacron that checks if on_ac_power is true before
running and if so then 'smartctl -t short /dev/sda' so that a short
selftest is run daily. Then do the same in cron.weekly so that weekly
a 'smartctl -t long /dev/sda' is run. That way the internal disk
firmware selftests will be run periodically. The anacron will ensure
that it gets run with the other housekeeping tasks. The check through
on_ac_power will ensure that it doesn't happen when the system is off
mobile on battery. Since I am not doing this myself I will leave that
as an exercise for the reader. :-)
Bob
Re: Recurring disk activity
On Sat, Jun 20, 2015 at 04:01:38PM +0530, Mayuresh wrote: Is your Load_Cycle_Count continuously increasing? Doesn't look like. It was 3634 when I started watching and over last few minutes it changed only to 3635. Install smartmontools. I also think think you should set up regular drive selftests. Ask if you want me to suggest something about this. Yes, please do suggest. Mayuresh. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150622155954.GA10398@odin
Re: Recurring disk activity
Mayuresh wrote: Bob Proulx wrote: Is your Load_Cycle_Count continuously increasing? Doesn't look like. It was 3634 when I started watching and over last few minutes it changed only to 3635. That still seems like a rather high load_cycle_count. And if it is increasing every minute then I would investigate the issue further. What does this say? hdparm -B /dev/sda Install smartmontools. I also think think you should set up regular drive selftests. Ask if you want me to suggest something about this. Yes, please do suggest. Is your laptop something that is mostly off but only sometimes on? Or something that is mostly on and sometimes mobile? Or something different? Mobile devices are a little hard to schedule selftests upon because we would want to do it sometime when the device is otherwise idle but on AC mains power. I don't know a perfect answer to mobile devices so let me start by explaining the default configuration, then explaining my preferred configuration for always on systems, then guessing at something good for a mobile device. Install the smartmontools package. The default configuration dynamically searches for disk drives. If smart detects a failure it will notify by sending email. Here is the default config: # The word DEVICESCAN will cause any remaining lines in this # configuration file to be ignored: it tells smartd to scan for all # ATA and SCSI devices. DEVICESCAN may be followed by any of the # Directives listed below, which will be applied to all devices that # are found. Most users should comment out DEVICESCAN and explicitly # list the devices that they wish to monitor. DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner The above is the default. It is documented in the smartd.conf man page. The options listed are: -d TYPE Set the device type: ata, scsi, marvell, removable, 3ware,N, hpt,L/M/N -n MODE No check. MODE is one of: never, sleep, standby, idle -m ADD Send warning email to ADD for -H, -l error, -l selftest, and -f -M TYPE Modify email warning behavior (see man page) The reason it recommends removing DEVICESCAN and replacing it with an explicit configuration is for systems with multiple disk drives. A server with two mirrored RAID1 disks might have one disk fail completely. If using DEVICESCAN it will only detect one disk and won't know there should be a second one. By explicitly telling it that there should be two disks it can report the failure on the missing one. The default config is a good safe default in that it is installable on any system and provides something. Unfortunately they never run any selftests. Therefore on an always on server I change the configuration to be this: # Monitor all attributes, enable automatic offline data collection, # automatic attribute autosave, and start a short self-test every # weekday between 2-3am, and a long self test Saturdays between 3-4am. # Ignore attribute 194 temperature change. # Ignore attribute 190 airflow temperature change. # On failure run all installed scripts (to send notification email). /dev/sda -a -o on -S on -s (S/../../[1-5]/03|L/../../6/03) -I 194 -I 190 -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sdb -a -o on -S on -s (S/../../[1-5]/03|L/../../6/03) -I 194 -I 190 -m root -M exec /usr/share/smartmontools/smartd-runner And for those options, all of these are on: -a Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198 -f Monitor for failure of any 'Usage' Attributes -H Monitor SMART Health Status, report if failed -f Monitor for failure of any 'Usage' Attributes -t Equivalent to -p and -u Directives -p Report changes in 'Prefailure' Normalized Attributes -u Report changes in 'Usage' Normalized Attributes -o VAL Enable/disable automatic offline tests (on/off) -S VAL Enable/disable attribute autosave (on/off) -I ID Ignore Attribute ID for -p, -u or -t Directive Those should be relatively straight forward. Basically all of the above is monitor important things and ignore unimportant things. -s REGE Start self-test when type/date matches regular expression -(see man page) That one is a mouthful. That one is where my comments come in to help. With the man page documentation the -s (S/../../[1-5]/03|L/../../6/03) option becomes this: start a short self-test every weekday between 2-3am, and a long self test Saturdays between 3-4am. That is the part that runs the selftests. Without -s it doesn't. The example file has examples that do almost exactly this. But those examples are commented out. For a server I like the above configuration where the selftests are run periodically. But for a mobile laptop this is more difficult because depending upon the user it might not be powered up at all during that time. Although if it is then it is likely to be on AC mains power. If it is on
Re: Recurring disk activity
Mayuresh wrote: I am a new Debian user. Welcome! :-) On a freshly purchased laptop I installed Debian jessie and I am facing a constant recurring disk noise. Is your Load_Cycle_Count continuously increasing? You mention a laptop and at one time there was a big problem with disk drives continuously parking the drive head. It has been a few years since I have heard of this problem. # apt-get install smartmontools # smartctl -a /dev/sda | grep Load_Cycle_Count # smartctl -a /dev/sda | grep Hours Look for parameter 193 Load_Cycle_Count and see if the raw value of it is continuously increasing. # hdparm -I /dev/sda | grep level Advanced power management level: disabled I think that should disable agressive power save management but I still think it is necessary to look directly at the load cycle count to know for certain. smart, hal : not installed Install smartmontools. I also think think you should set up regular drive selftests. Ask if you want me to suggest something about this. Bob signature.asc Description: Digital signature
Recurring disk activity
I am a new Debian user. On a freshly purchased laptop I installed Debian jessie and I am facing a constant recurring disk noise. Have searched the forums on various lists and tried out suggested solutions. Following is the relevant information: Laptop spec: http://support.hp.com/us-en/product/HP-15-r200-Notebook-PC-series/7486447/model/7748035/document/c04576750/ # uname -a Linux hp 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux # hdparm -I /dev/sda | grep level Advanced power management level: disabled # iotop -obtqqq 15:56:4389 be/4 root0.00 B/s0.00 B/s 0.00 % 0.13 % [kworker/1:1] 15:56:4689 be/4 root0.00 B/s0.00 B/s 0.00 % 0.14 % [kworker/1:1] 15:56:4889 be/4 root0.00 B/s0.00 B/s 0.00 % 0.14 % [kworker/1:1] 15:56:4989 be/4 root0.00 B/s0.00 B/s 0.00 % 0.12 % [kworker/1:1] 15:56:5189 be/4 root0.00 B/s0.00 B/s 0.00 % 0.12 % [kworker/1:1] 15:56:5389 be/4 root0.00 B/s0.00 B/s 0.00 % 0.12 % [kworker/1:1] 15:56:5589 be/4 root0.00 B/s0.00 B/s 0.00 % 0.13 % [kworker/1:1] No file in /var/log is seen changing frequently. There is no X installed, leave alone any desktop manager. It's a bare bone installation which is merely started. smart, hal : not installed The laptop has a builtin freedos partition. If I boot to that there is no disk noise. Thus it may not be a drive problem. Would appreciate help in fixing the unnecessary disk Mayuresh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150620103138.GA12790@odin
Re: Recurring disk activity
On Sat, Jun 20, 2015 at 04:01:38PM +0530, Mayuresh wrote:
On a freshly purchased laptop I installed Debian jessie and I am facing a
constant recurring disk noise.
Further to the details in previous posts, I have nearly switched off all
services except ssh and networking now.
# service --status-all | grep \+ | awk '{print $4}'
[ ? ] qemu-system-x86
[ ? ] vboxautostart-service
networking
ssh
vboxballoonctrl-service
vboxdrv
vboxweb-service
I am not able to stop vbox* services, though virtualbox is not running.
Still it's not stopping disk activity.
Mayuresh
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150620165323.GA760@odin
