2

I have 3 physical drives - SSD with / mounted, 1st HDD used as /var and /home, 2nd HDD - recovery storage for backups. The HDD with backups should stay most of the time in standby and unmounted state caused by cron and bash scripts with umount and hdparm -y.

The problem is external USB-drives mounting/umounting (with GUI or terminal) causes resuming of sleeping drive from standby state.

Deeper investigation shows that mount and umount utilities execute dumpe2fs -h /dev/sdXn command for every partition (including unmounted) of every drive installed, which causes directly sleeping drives wake up.

For example, if the external USB-drive/stick /dev/sdd is being mounted/dismounted, this causes in my case consequent execution of the commands (pieces from real log with some explanations):

dumpe2fs -h /dev/sda1 #this is / (root) partition at SSD
[...]
dumpe2fs -h /dev/sdc4 #this is /var partition at HDD #1
[...]
dumpe2fs -h /dev/sdc3 #this is /home partition at HDD #1
[...]
dumpe2fs -h /dev/sdb1 #this is recovery storage partition at HDD #2
[...]

Ubuntu 16.04 and earlier versions (I have migrated from Red Hat to Debian and Ubuntu in 2006) haven't such the strange behaviour. Thus, we can come to resonable conclusion the behavior caused by a bug of Ubuntu 18.04. Is there any way to solve the problem?

Note: There is related question (but not a duplicate) in Unix & Linux community: Why is dumpe2fs called without user interaction?.

UPDATE. I have discovered solution for the problem - it will be posted some later today. The problem is solved. My deepest appreciation for help to @神秘德里克 - thank you so much, friend!

Bob
  • 1,135
  • 6
  • 9
  • So, did you try the suggestion in https://unix.stackexchange.com/questions/408757/why-is-dumpe2fs-called-without-user-interaction and looked into the logfile generated to see which process is calling `dumpe2fs`? – Thomas Jul 22 '18 at 09:30
  • So did you try the answer in that question? Are you sure dumpe2fs get called every time you mount sdd? How about change that script a little to find out dump e2fs process's parent all the way to init? Did you check whether there is any wrong your mount program like it's actually a script not normal ELF? – 炸鱼薯条德里克 Jul 22 '18 at 09:33
  • @Thomas Thank you for your reply! Yes, I have followed and got help from the suggestion which has allowed to identify what happens during ordinary USB-stick use. The whole process looks very simple from point of view of user: `mount` calls `dumpe2fs` for every `ext4` partition of every disk attached. – Bob Jul 22 '18 at 09:41
  • @神秘德里克 Thank you for swift respond! Yes, `dumpe2fs` get called every time `sdd` drive mount/umount applied without any exclusions for different USB-drives. I'll try to explore some more details according to your suggestion to find parent processes and post the report here. – Bob Jul 22 '18 at 10:03
  • @神秘德里克 I don't consider something else besides Ubuntu 18.04 specific problem as the bug has been discovered immediately on fresh installed Ubuntu 18.04. My backup drive is WD Green series and it produces very specific noise which I hear quite well. I have spinned down the drive manually from terminal on fresh system and some time later detected the noise of my WD after insertion of USB-stick. Afterwards I have repeated the process many times - the problem is systematic. – Bob Jul 22 '18 at 10:04
  • 1
    I cannot confirm that the commands `mount`/`umount` do trigger a `dumpe2fs` on all devices. Just tested in a Ubuntu 18.04 VM. I guess you are running in a Desktop environment. In that case `udisks2` is investigating the attached disks on USB add/removal to make it accessible in the GUI for the user. – Thomas Jul 22 '18 at 10:08
  • 1
    According to Thomas, if you're using udisks or some other tools instead of mount program, then other logic might happen. Please don't tell me when you say mount/umount you are referring to some Desktop Environment based auto mount functionality. As far I I know , mount/umount from util-linux never call dumpe2fs command. – 炸鱼薯条德里克 Jul 22 '18 at 10:40
  • @Thomas Yes, exactly, Desktop environment is being used. Please, look at log produced during single USB-stick insertion: https://pastebin.com/QquqYKmm - you're right, `udisks` is involved in the process, but there is a strange point - if I dismount, for example, the USB-stick manually `sudo umount /media/user/usb-stick` the system produces absolutely same result and calls `dumpe2fs` in absolutely same way. – Bob Jul 22 '18 at 10:42
  • @神秘德里克 The manually executed `sudo umount /media/user/usb-stick` for USB-stick produces same result. Look at the log produced immediately after your comment was posted: https://pastebin.com/3S55JuK5 – Bob Jul 22 '18 at 10:48
  • 2
    Uh…Here's the thing, I'm a Chinese guy travelling on a train, my network can't access pastebin, so my personal suggestions is , since Ubuntu 18.04 use systemd, you can disable udisks service, umount all partitions on sdd, reboot, try to do mount/umount all by yourself, see what happened. Because I am not familiar with udisks2, maybe it's monitoring mount points and try to do wired stuff even when you umount manually…I guess? – 炸鱼薯条德里克 Jul 22 '18 at 11:09
  • 2
    @神秘德里克 Which pastebin service is available for you? I have followed your suggestion: stopped udisks daemon `systemctl stop udisks2.service`, checked its status: `systemctl status udisks2.service` (it was stopped) and inserted USB-drive. As result the stick wasn't mounted automatically. I have mounted it manually `mount /dev/sdd1 /media/user/stick` and **the problem has disappeared** - no `dumpe2fs` was called. – Bob Jul 22 '18 at 11:54
  • 1
    @神秘德里克 Dismounting `umount /media/user/stick` hasn't called `dumpe2fs` too. I'd say everything looks fine besides automatic disks mounting. But, we have some definite pin already: not `mount/umount` but `udisks2` daemon is the reason of problem. – Bob Jul 22 '18 at 11:54
  • @神秘德里克 I have solved the problem. As the question is on hold for strange reason, I'm not able to post solution. – Bob Jul 22 '18 at 18:40
  • @神秘德里克 Thank you so much for help, Friend! – Bob Jul 22 '18 at 19:10
  • 2
    I reopened this since you deleted the copy on AU. I also removed your discussion of how you were treated since that doesn't belong here. Let's just try and keep the discussion limited to _technical_ issues please. – terdon Jul 23 '18 at 17:26
  • @terdon Thank you so much! I'll post today answer with the problem solution. – Bob Jul 24 '18 at 08:05
  • @Bob, so what's the solution? I have a similar problem... – vedg Jan 05 '19 at 14:51

1 Answers1

1

udisksd calls dumpe2fs -h /dev/sd?? command for each ext2, ext3 and ext4 partition when the service is started and when it mounts/unmounts any disk. Any HDD that contains at least one ext* partition is waked by udisksd=>dumpe2fs.

Much more details can be found in comments to this udisks bug: https://github.com/storaged-project/udisks/issues/611. The bug is fixed in udisks 2.8.4, so it no longer wakes any HDDs when an unrelated partition is mounted or unmounted.

There is a similar question and answer here: https://superuser.com/questions/1371955/why-one-of-two-hdds-wakes-from-sleep-during-the-first-linux-graphical-login.

vedg
  • 153
  • 6