[SOLVED] Linux Mint

GPGAgent · 07-11-2020, 05:40 PM

Even when the machine is idle, there is activity to the disk.
What's the best way to figure out what's doing it?
Once I know that I can try to reduce or stop it.
I've attached htop output

Code:

jonk@dave:~$ cat /proc/sys/vm/swappiness
10
jonk@dave:~$

and

Code:

jonk@dave:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           11Gi       1.8Gi       7.8Gi       191Mi       2.1Gi       9.4Gi
Swap:         2.0Gi          0B       2.0Gi
jonk@dave:~$

and a bit more info about the disk

Code:

jonk@dave:~$ sudo fdisk -l
[sudo] password for jonk:##########
Disk /dev/sda: 1.84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Hitachi HUA72302
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: 0x289f73ed

Device     Boot   Start        End    Sectors  Size Id Type
/dev/sda1  *       2048    1050623    1048576  512M  b W95 FAT32
/dev/sda2       1052670 3907028991 3905976322  1.8T  5 Extended
/dev/sda5       1052672 3907028991 3905976320  1.8T 83 Linux


Disk /dev/sdb: 7.28 TiB, 8001563221504 bytes, 15628053167 sectors
Disk model: Backup+ Hub BK  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D42CC68E-B160-4AE4-B6C6-828F95D96FBC

Device     Start         End     Sectors  Size Type
/dev/sdb1   2048 15628052479 15628050432  7.3T Linux filesystem
jonk@dave:~$

and about the cpu

Code:

jonk@dave:~$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   40 bits physical, 48 bits virtual
CPU(s):                          16
On-line CPU(s) list:             0-15
Thread(s) per core:              2
Core(s) per socket:              4
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           44
Model name:                      Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
Stepping:                        2
Frequency boost:                 enabled
CPU MHz:                         1600.231
CPU max MHz:                     2395.0000
CPU min MHz:                     1596.0000
BogoMIPS:                        4800.56
Virtualisation:                  VT-x
L1d cache:                       256 KiB
L1i cache:                       256 KiB
L2 cache:                        2 MiB
L3 cache:                        24 MiB

and its running Mint 20 XFCE

Code:

jonk@dave:~$ uname -a
Linux dave 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
jonk@dave:~$ 
jonk@dave:~$ cat /etc/os-release
NAME="Linux Mint"
VERSION="20 (Ulyana)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 20"
VERSION_ID="20"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.ubuntu.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=ulyana
UBUNTU_CODENAME=focal
jonk@dave:~$

frankbell · 07-11-2020, 08:01 PM

Try the top or htop command. See their man pages for details.

Note that, even when you are not actively using the machine, processes and daemons will still be running behind the scenes, as it were. The only time a computer is completely idle is when it's powered off.

You might find this article helpful: https://www.cyberciti.biz/faq/find-o...ound-on-linux/

syg00 · 07-11-2020, 08:50 PM

Quote:

Originally Posted by GPGAgent

I've attached htop output

I'd be looking at indexing software - was tracker to blame when I looked at this sort of thing. But anything doing (semi-)constant logging could be to blame.

tinfoil3d · 07-11-2020, 08:57 PM

Wait, what? I don't even see where did you find "disk activity", you'd be running iotop, right?

GPGAgent · 07-12-2020, 03:06 AM

Quote:

Originally Posted by tinfoil3d

Wait, what? I don't even see where did you find "disk activity", you'd be running iotop, right?

Exactly my point, I can hear the disk activity - constant pattern of sound, precisely the same as when I save file. And of course the disk activity led is lit

tinfoil3d · 07-12-2020, 06:25 AM

You've never mentioned that. Does it still happen when you boot into it in rescue mode(no gui)? Does it still happen in livecd? Maybe the disk is dying btw. Or you just need to run iotop anyway. What does iotop say?

GPGAgent · 07-12-2020, 06:49 AM

Quote:

Originally Posted by tinfoil3d

You've never mentioned that. Does it still happen when you boot into it in rescue mode(no gui)? Does it still happen in livecd? Maybe the disk is dying btw. Or you just need to run iotop anyway. What does iotop say?

I may be worrying about nothing! iotop doesn't show anything of too much concern, unless I'm using it incorrectly

Code:

jonk@dave:~$ sudo iotop

and iostat

Code:

jonk@dave:~$ iostat -h
Linux 5.4.0-40-generic (dave) 	12/07/20 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.9%    0.0%    0.5%    0.5%    0.0%   97.0%

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
    13.26       302.3k       222.3k         0.0k     876.4M     644.6M       0.0k sda


jonk@dave:~$

michaelk · 07-12-2020, 07:04 AM

In addition to logs ext4 journal commits happen every 5 seconds. You can increase the time but if you lose power that would be how much data you could lose.

GPGAgent · 07-12-2020, 07:21 AM

Quote:

Originally Posted by michaelk

In addition to logs ext4 journal commits happen every 5 seconds. You can increase the time but if you lose power that would be how much data you could lose.

I've looked up how to do this but it looks a bit too difficult, so I may hold off for now, unless there is a nice simple way, thanks for the info

Code:

jonk@dave:~$ more /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=6e725920-1c32-4931-bab9-fc8c12d01128 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=0628-D3D6  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
jonk@dave:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            5.9G     0  5.9G   0% /dev
tmpfs           1.2G  1.7M  1.2G   1% /run
/dev/sda5       1.8T   28G  1.7T   2% /
tmpfs           5.9G  129M  5.8G   3% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           5.9G     0  5.9G   0% /sys/fs/cgroup
/dev/sda1       511M  4.0K  511M   1% /boot/efi
tmpfs           1.2G   28K  1.2G   1% /run/user/1000

syg00 · 07-12-2020, 07:37 AM

I was going to mention iotop would likely produce that for low level background I/O. It's a sampler that takes averages over time - you need something that logs (all) actual traffic. I set a kernel trace to trap it but other tools now exist in user-space, I'll see what my notes say.
The I/O scheduler commit time that michaelk mentions is more of a symptom of something else doing actual I/O - changing the time delta merely moves the goal posts.

syg00 · 07-12-2020, 07:57 AM

OK - have a look at fatrace. It attaches ionotify for all mounted filesystems but ignores the pseudo filesystems like /proc. So it see calls to the I/O subsystem rather than actual physical I/O to the disk but should suffice. It'll tell you what processes are calling I/O to what files.
You'll be surprised how much I/O is going on all the time. On a (really) idle gnome system a 60 second run got 1976 hits - only 7 of which were writes, all by gvfs.

tinfoil3d · 07-12-2020, 09:01 AM

If even fatrace shows nothing there may be a reason to get concerned about it because the HDD may be failing, however it's still strange that the busy LED is on. I'd back up before posting to LQ initially if I were you.
Try live/other os/emergency mode to check if the symptoms are still there, if they are, also post

Code:

smartctl --all /dev/sda

. After backing up, that is.

GPGAgent · 07-12-2020, 09:48 AM

Well all seems okay after a short test

Code:

jonk@dave:~$ sudo smartctl --test=short /dev/sda1
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-40-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Sun Jul 12 15:42:24 2020 BST
Use smartctl -X to abort test.
jonk@dave:~$ 



jonk@dave:~$ sudo smartctl --capabilities /dev/sda1
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-40-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
General SMART Values:
Offline data collection status:  (0x85)	Offline data collection activity
					was aborted by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(20946) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 ( 349) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

and ditto for sda5

Code:

jonk@dave:~$ sudo smartctl --test=short /dev/sda5
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-40-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Sun Jul 12 15:45:45 2020 BST
Use smartctl -X to abort test.



jonk@dave:~$ sudo smartctl --capabilities /dev/sda5
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-40-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
General SMART Values:
Offline data collection status:  (0x85)	Offline data collection activity
					was aborted by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.

and a quick df -h

Code:

jonk@dave:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            5.9G     0  5.9G   0% /dev
tmpfs           1.2G  1.7M  1.2G   1% /run
/dev/sda5       1.8T   28G  1.7T   2% /
tmpfs           5.9G  163M  5.7G   3% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           5.9G     0  5.9G   0% /sys/fs/cgroup
/dev/sda1       511M  4.0K  511M   1% /boot/efi
tmpfs           1.2G   16K  1.2G   1% /run/user/1000
jonk@dave:~$

So I think I'll just keep an eye on it - cheers for the tips folks