HDD standby interrupted

adrhc · 01-13-2018, 07:04 AM

Hi, I have 2 HDD, one with the linux installation (ext4, /dev/sda) and another with a windows installation (NTFS, /dev/sdb). I scarcely use /dev/sdb so I put it in standby (e.g. I use gnome-disks for this). The problem is that when I'm using gedit or Visual Studio Code to open a specific text file (not link) from my linux home the standby is interrupted. I can test this with the command:

Code:

hddtemp /dev/sd{a,b}

(it shows drive is sleeping when in standby). I tried

Code:

sudo lsof /dev/sdb

to find out which program is using /dev/sdb but nothing is found. Any suggestions?

Code:

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

Code:

uname -a

Linux gigi-desktop 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

hydrurga · 01-13-2018, 08:37 AM

Check your gedit file history - it perhaps checks all files in the history to see if they are reachable and hence valid.

adrhc · 01-13-2018, 01:39 PM

Hm, I just opened gedit then opened the file mentioned above (let' name it zzz.txt) and the HDD standby was not interrupted. Usually the interrupt felt like was something related to the gedit's history as you (@hydrurga) pointed. Visual Studio Code was already opened with zzz.txt also opened; I closed both then restarted both (Visual Studio Code restores automatically its previously opened files). HDD standby was again not interrupted though many times ago just opening the gedit's history the HDD standby was interrupted.

hydrurga · 01-13-2018, 02:15 PM

Perhaps the gedit history no longer includes a file from /dev/sdb as it has been supplanted by more recent files? You can test that hypothesis.

Also, try opening files in different ways. Perhaps the activity only happens, for example, when the File-Open dialog is used (because gedit scans /dev/sdb to help populate its list of available drives in the dialog).

I think you should simplify things and only test gedit, not running Visual Studio Code at the same time. You want to minimise the factors at play.

adrhc · 01-14-2018, 04:25 AM

Hi, I give it a try today. I did exactly this:
- run hddtemp /dev/sd{a,b}
- opened gedit version 3.18.3
- clicked the "Open" button from toolbar -> I immediately heard the HDD starting; sudo lsof /dev/sdb showed nothing.
- run hddtemp /dev/sd{a,b} -> confirmed HDD starting

@hydrurga
I left the computer running (ofen I do this) from my previous post and since then gedit was not used (it was night so I was sleeping). So I guess it has nothing to do with the gedit history unless it's cached somehow in memory which after a while is flushed. Besides, gedit history presents no /dev/sdb file.

yeah, it's a tough problem

norobro · 01-14-2018, 12:10 PM

Quote:

Originally Posted by adrhc

Code:

sudo lsof /dev/sdb

to find out which program is using /dev/sdb but nothing is found. Any suggestions?

From the lsof man page:

Code:

names    These  are  path  names  of  specific  files to list.  Symbolic links are resolved
            before use.  The first name may be separated from the preceding options  with  the
            ``--'' option.

            If  a  name is the mounted-on directory of a file system or the device of the file
            system, lsof will list all the files open on the file system.  To be considered  a
            file  system,  the name must match a mounted-on directory name in mount(8) output,
            or match the name of a block device associated with a mounted-on  directory  name.

You need to either include the partition number or use the mount point to see any open files on the device. For example:

Code:

sudo lsof /dev/sda1
sudo lsof /mount_point

An aside:

Quote:

... I scarcely use /dev/sdb ...

Why not mount it only when you use it? Then unmount it and put it back to sleep.

adrhc · 01-14-2018, 01:50 PM

The previous test I wrongly used lsof but before it I was usually using the mount_point version (sudo lsof /mnt/1TB) and still no result. I'll repeat anyway the test but surely won't change anything.

Quote:

Why not mount it only when you use it? Then unmount it and put it back to sleep.

That's not a bad idea but still I want to find the solution not just an workaround.
Anyway it's a good idea for the future test identical to the above one; I wonder what would happen when /dev/sdb is unmounted.

adrhc · 01-16-2018, 10:13 AM

Hi, I tried again this way:
- umount /mnt/1TB
- put /dev/sdb to standby
- run hddtemp /dev/sd{a,b} -> /dev/sdb is sleeping
- opened gedit version 3.18.3 from term (just to check for possible errors)
- clicked the "Open" button from toolbar -> nothing unusual happens
- run hddtemp /dev/sd{a,b} -> /dev/sdb still sleeping
I did the test 3 times with the computer being not directly used for about 8h before the test; it is however remotely used because it hosts my websites and blog.

After this test I immediately tried again the previous days test:
- mounted bach /mnt/1TB
- put /dev/sdb to standby
- run hddtemp /dev/sd{a,b} -> /dev/sdb is sleeping
- opened gedit version 3.18.3 from term
- clicked the "Open" button from toolbar -> I immediately heard the HDD starting; sudo lsof /dev/sdb showed nothing
- run hddtemp /dev/sd{a,b} -> confirmed HDD starting

What could be the cause for gedit to start the HDD?

norobro · 01-16-2018, 05:23 PM

I can't replicate this behavior on Debian Sid or Ubuntu 17.10 Artful Aarvark both with gedit v. 3.22.1.

Perhaps this was the fix in 3.20: https://git.gnome.org/browse/gedit/c...990edb88e7f5ae

adrhc · 01-17-2018, 09:51 AM

The 1th suspect is indeed the recent files list (it's merely the Open button click that triggers the HDD sleeping interruption). The problem is that I have no file from the sleeping HDD in the recent files list. Is gedit checking more than the recent files list?

rknichols · 01-17-2018, 12:37 PM

If you're really curious, run gedit under strace with the "-e trace=file" option and see what it's looking at.

It's going to be very difficult to keep a disk in standby if it contains a mounted filesystem. Too many tools poke around "getting the lay of the land", so to speak, and causing the disk to spin back up. Heck, I have one disk with some encrypted partitions that aren't even unlocked, and every time I'm doing any sort of system maintenance some tool probes that disk and causes it to spin up.

adrhc · 01-18-2018, 07:39 AM

@rknichols
good test idea, thanks

I used:

Code:

strace -e trace=open,read,write -o $HOME/strace-gedit.log gedit

Immediately after pressing the Open button the HDD sleeping was interrupted.
Does anyone see something spectacular in the attached log file?

This is the sleeping HDD mount:

Code:

mount

/dev/sdb1 on /mnt/1TB type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper= udisks2)

Code:

fdisk -l /dev/sdb

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x06ac2835
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 1953523711 1953521664 931.5G 7 HPFS/NTFS/exFAT

rknichols · 01-18-2018, 08:48 AM

Quote:

Originally Posted by adrhc

I used:

Code:

strace -e trace=open,read,write -o $HOME/strace-gedit.log gedit

Immediately after pressing the Open button the HDD sleeping was interrupted.
Does anyone see something spectacular in the attached log file?

I don't see anything relevant in that log file, but that trace is missing a lot of other things that access files, notably "stat()" and "lstat()". My suggested "trace=file" covers all syscalls that take a filename as an argument. Using "trace=file,read,write" looks like a useful addition, but getting everything that takes a filename is essential.

norobro · 01-18-2018, 11:17 AM

Quote:

Originally Posted by adrhc

Does anyone see something spectacular in the attached log file?

Take a look in the following two files and see if any files on your mounted drive are listed. On my system there are several old files listed that I have since deleted. I think because of the change in gedit 3.20 the drive isn't accessed.

Code:

$ grep recently strace-gedit.log 
open("/home/gigi/.local/share/recently-used.xbel", O_RDONLY) = 14
open("/home/gigi/.local/share/recently-used.xbel.PUQDDZ", O_RDWR|O_CREAT|O_EXCL, 0666) = 15

You might try moving those files out of the way and running gedit to see if your drive still spins up.

adrhc · 01-19-2018, 08:15 AM

@rknichols

I tried

Code:

strace -e trace=file -o $HOME/strace-file-gedit.log gedit

with the result attached. The HDD sleeping was again interrupted.

Any clue?

PS: the log is missing its first part (~ 256KB) - I had to remove it in order to be allowed to attach the file