| View previous topic :: View next topic |
| Author |
Message |
spica
Apprentice
Joined: 04 Jun 2021
Posts: 287
|
 Posted: Mon Mar 04, 2024 12:59 am Post subject: [solved] usb hdd power saving |
 |
|
How to configure powersaving for usb hdd properly?
The disk is vibrating all the time.
If I run hdparm -B 1 /dev/sdb and the disk is not mounted then it stops vibrating after 5-10 seconds.
If it is mounted then this trick seems does not work.
hdparm -I
lsusb
kernconf
Last edited by spica on Tue Mar 05, 2024 12:08 pm; edited 1 time in total |
|
| Back to top |
|
 |
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 222
Location: Pennsylvania, USA
|
| Posted: Mon Mar 04, 2024 2:06 am Post subject: Re: usb hdd power saving |
|
|
| spica wrote: | If I run hdparm -B 1 /dev/sdb and the disk is not mounted then it stops vibrating after 5-10 seconds.
If it is mounted then this trick seems does not work. |
What filesystem are you mounting that keeps the drive spinning ? Maybe that filesystem is in use ? For example, see https://wiki.gentoo.org/wiki/SSD#XDG_cache_on_tmpfs.
There is an utility, sys-block/blktrace, that can tell you what process is causing the disk to spin up. I forget how to use it, you'll have to emerge it and read the docs.
See also https://wiki.gentoo.org/wiki/Power_management/Guide/en#Using_Laptop_Mode_Tools to help keep the drive on standby for longer periods.
(Personally, I gave up on spinning down my laptop's HDD, since powertop shows the display and wifi as the the two largest power hogs, well above the disk.) |
|
| Back to top |
|
|
spica
Apprentice
Joined: 04 Jun 2021
Posts: 287
|
| Posted: Tue Mar 05, 2024 12:01 pm Post subject: Re: usb hdd power saving |
|
|
| sublogic wrote: | | What filesystem are you mounting that keeps the drive spinning ? Maybe that filesystem is in use ? |
This question prompts crucial insights. The disk, formatted as ext4, was void of any files. I mounted it onto /mnt/usb, to be sure nothing goes to work with that directory. Despite the absence of file operations, blktrace revealed CPU cycles engaged in communication with the disk.
Then I enabled CONFIG_USB_STORAGE_DEBUG, and dmesg unveiled a recurring activity of WRITE_10, persistently echoing at an constant interval of approximately 1.5 seconds: | Code: | # dmesg | grep Command
[ 263.492740] Command WRITE_10 (10 bytes)
[ 263.492753] Bulk Command S 0x43425355 T 0x81e L 1048576 F 0 Trg 0 LUN 0 CL 10
[ 263.497904] Command WRITE_10 (10 bytes)
[ 263.497915] Bulk Command S 0x43425355 T 0x81f L 1048576 F 0 Trg 0 LUN 0 CL 10
[ 265.039386] Command WRITE_10 (10 bytes)
[ 265.039398] Bulk Command S 0x43425355 T 0x820 L 1048576 F 0 Trg 0 LUN 0 CL 10
[ 265.044523] Command WRITE_10 (10 bytes)
[ 265.044534] Bulk Command S 0x43425355 T 0x821 L 1048576 F 0 Trg 0 LUN 0 CL 10
[ 266.586065] Command WRITE_10 (10 bytes)
[ 266.586077] Bulk Command S 0x43425355 T 0x822 L 1048576 F 0 Trg 0 LUN 0 CL 10 |
So, the question is not just good – it's the pivotal question. I decided to try to format with something different than ext4: | Code: | | mkfs.btrfs /dev/sdb1 -f -m dup |
And then I mounted the disk again, but dmesg stayed silent – that was a new observation.
Taking further action, I invoked | Code: | | hdparm -B 1 /dev/sdb |
and the disk went to sleep in ~10 seconds. To test disk responsiveness, I created a file touch /mnt/usb/test.txt in mounted directory, and the disk was silent. Then I ran sync and the disk vibrated for 10 or 15 seconds and then became silent again – so it works with btrfs as I expected. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21639
|
| Posted: Tue Mar 05, 2024 4:00 pm Post subject: |
|
|
| For how long had ext4 been the filesystem on that drive? If it was very new, perhaps ext4's bg_init feature was still writing metadata, and the kernel would cease that once the metadata was fully initialized. |
|
| Back to top |
|
|
spica
Apprentice
Joined: 04 Jun 2021
Posts: 287
|
| Posted: Tue Mar 05, 2024 9:07 pm Post subject: |
|
|
| Hu wrote: | | For how long had ext4 been the filesystem on that drive? If it was very new, perhaps ext4's bg_init feature was still writing metadata, and the kernel would cease that once the metadata was fully initialized. |
Yes, it was just formatted ext4 and it spent a couple of hours attached to the server.
I did an additional experiment – I told the formatter to make tables and journal right now:
| Code: | # mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
/dev/sdb1 contains a btrfs file system
Proceed anyway? (y,N) y
Creating filesystem with 976754176 4k blocks and 244195328 inodes
Filesystem UUID: aa8454e0-3e8a-4f94-9b37-45e5c5e34c59
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done |
And this helped too. I think, we found the answer why: the system was creating tables in background, and it seems it does it slowly, and these couple of hours were not enough for stabilization of the filesystem. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
