I have an external hard disk with a ZFS pool on it. The data is accessed very infrequently so I would like to drive to go to sleep after some inactivity, which I set to 10min: hdparm -S 120 /dev/disk/by-id/usb-Seagate_Expansion_Desk_NAABDT6W-0\:0 With a cron script I check the status of the drive over time: hdparm -C /dev/disk/by-id/usb-Seagate_Expansion_Desk_NAABDT6W-0\:0 This works sometimes but most of the time, the drive remains in "active/idle" all the time, even if no access occurs. The ZFS pool is not performing scrubs. There are no zvols. All datasets (some of them encrypted) are mounted to under /zpseagate8tb/ (and /zpseagate8tb_bind/ for use in LXC containers). I confirmed no file descriptors to any of the datasets are open: # lsof -w | grep zpseagate8tb # What else could be preventing the drive from going to sleep?

I set the APM level and standby timeout of my HDDs during boot with a udev rule: ACTION=="add|change", KERNEL=="sd[b-z]", ATTR{queue/rotational}=="1", RUN+="/usr/bin/hdparm -B 63 -S 36 /dev/%k" I checked that the rule gets executed by touching a file in the RUN command instead and by udevadm test /sys/class/block/sdb: calling: test version 227 This program is for debugging only, it does not run any program specified by a RUN key. It may show incorrect results, because some values may be different, or not available at a simulation run. === trie on-disk === tool version: 227 file size: 6660537 bytes header size 80 bytes strings 1715721 bytes nodes 4944736 bytes Load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Created link configuration context. timestamp of '/etc/udev/rules.d' changed Reading rules file: /usr/lib/udev/rules.d/10-dm.rules Reading rules file: /usr/lib/udev/rules.d/11-dm-lvm.rules Reading rules file: /usr/lib/udev/rules.d/13-dm-disk.rules Reading rules file: /etc/udev/rules.d/50-hdparm.rules Reading rules file: /usr/lib/udev/rules.d/50-udev-default.rules Reading rules file: /etc/udev/rules.d/51-tests.rules Reading rules file: /usr/lib/udev/rules.d/60-block.rules Reading rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules Reading rules file: /usr/lib/udev/rules.d/60-drm.rules Reading rules file: /usr/lib/udev/rules.d/60-evdev.rules Reading rules file: /usr/lib/udev/rules.d/60-pcmcia.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-input.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules Reading rules file: /usr/lib/udev/rules.d/60-serial.rules Reading rules file: /usr/lib/udev/rules.d/63-md-raid-arrays.rules Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules Reading rules file: /usr/lib/udev/rules.d/64-md-raid-assembly.rules Reading rules file: /usr/lib/udev/rules.d/69-dm-lvm-metad.rules Reading rules file: /usr/lib/udev/rules.d/70-mouse.rules Reading rules file: /usr/lib/udev/rules.d/70-power-switch.rules Reading rules file: /usr/lib/udev/rules.d/70-uaccess.rules Reading rules file: /usr/lib/udev/rules.d/71-seat.rules Reading rules file: /usr/lib/udev/rules.d/73-seat-late.rules Reading rules file: /usr/lib/udev/rules.d/75-net-description.rules Reading rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules Reading rules file: /usr/lib/udev/rules.d/78-sound-card.rules Reading rules file: /usr/lib/udev/rules.d/80-drivers.rules Reading rules file: /usr/lib/udev/rules.d/80-net-setup-link.rules Reading rules file: /usr/lib/udev/rules.d/85-regulatory.rules Reading rules file: /usr/lib/udev/rules.d/90-vconsole.rules Reading rules file: /usr/lib/udev/rules.d/95-dm-notify.rules Reading rules file: /usr/lib/udev/rules.d/99-systemd.rules rules contain 24576 bytes tokens (2048 * 12 bytes), 11755 bytes strings 1710 strings (21440 bytes), 1124 de-duplicated (10272 bytes), 587 trie nodes used RUN '/usr/bin/hdparm -B 63 -S 36 /dev/%k' /etc/udev/rules.d/50-hdparm.rules:1 GROUP 6 /usr/lib/udev/rules.d/50-udev-default.rules:55 RUN '/usr/bin/touch /tmp/udev-%k' /etc/udev/rules.d/51-tests.rules:1 IMPORT 'ata_id --export /dev/sdb' /usr/lib/udev/rules.d/60-persistent-storage.rules:22 starting 'ata_id --export /dev/sdb' 'ata_id --export /dev/sdb'(out) 'ID_ATA=1' 'ata_id --export /dev/sdb'(out) 'ID_TYPE=disk' 'ata_id --export /dev/sdb'(out) 'ID_BUS=ata' 'ata_id --export /dev/sdb'(out) 'ID_MODEL=ST2000VN000-1HJ164' 'ata_id --export /dev/sdb'(out) 'ID_MODEL_ENC=ST2000VN000-1HJ164\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20' 'ata_id --export /dev/sdb'(out) 'ID_REVISION=SC60' 'ata_id --export /dev/sdb'(out) 'ID_SERIAL=ST2000VN000-1HJ164_W7209GX3' 'ata_id --export /dev/sdb'(out) 'ID_SERIAL_SHORT=W7209GX3' 'ata_id --export /dev/sdb'(out) 'ID_ATA_WRITE_CACHE=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_WRITE_CACHE_ENABLED=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_HPA=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_HPA_ENABLED=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_PM=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_PM_ENABLED=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_SECURITY=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_SECURITY_ENABLED=0' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=236' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=236' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_SMART=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_SMART_ENABLED=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_PUIS=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_PUIS_ENABLED=0' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_APM=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_APM_ENABLED=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_FEATURE_SET_APM_CURRENT_VALUE=63' 'ata_id --export /dev/sdb'(out) 'ID_ATA_DOWNLOAD_MICROCODE=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_SATA=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_SATA_SIGNAL_RATE_GEN2=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_SATA_SIGNAL_RATE_GEN1=1' 'ata_id --export /dev/sdb'(out) 'ID_ATA_ROTATION_RATE_RPM=5900' 'ata_id --export /dev/sdb'(out) 'ID_WWN=0x5000c5008b32e037' 'ata_id --export /dev/sdb'(out) 'ID_WWN_WITH_EXTENSION=0x5000c5008b32e037' Process 'ata_id --export /dev/sdb' succeeded. LINK 'disk/by-id/ata-ST2000VN000-1HJ164_W7209GX3' /usr/lib/udev/rules.d/60-persistent-storage.rules:36 IMPORT builtin 'path_id' /usr/lib/udev/rules.d/60-persistent-storage.rules:54 LINK 'disk/by-path/pci-0000:01:00.0-ata-1' /usr/lib/udev/rules.d/60-persistent-storage.rules:55 IMPORT builtin 'blkid' /usr/lib/udev/rules.d/60-persistent-storage.rules:66 probe /dev/sdb raid offset=0 LINK 'disk/by-id/wwn-0x5000c5008b32e037' /usr/lib/udev/rules.d/60-persistent-storage.rules:73 handling device node '/dev/sdb', devnum=b8:16, mode=0660, uid=0, gid=6 preserve permissions /dev/sdb, 060660, uid=0, gid=6 preserve already existing symlink '/dev/block/8:16' to '../sdb' found 'b8:16' claiming '/run/udev/links/\x2fdisk\x2fby-id\x2fata-ST2000VN000-1HJ164_W7209GX3' creating link '/dev/disk/by-id/ata-ST2000VN000-1HJ164_W7209GX3' to '/dev/sdb' preserve already existing symlink '/dev/disk/by-id/ata-ST2000VN000-1HJ164_W7209GX3' to '../../sdb' found 'b8:16' claiming '/run/udev/links/\x2fdisk\x2fby-id\x2fwwn-0x5000c5008b32e037' creating link '/dev/disk/by-id/wwn-0x5000c5008b32e037' to '/dev/sdb' preserve already existing symlink '/dev/disk/by-id/wwn-0x5000c5008b32e037' to '../../sdb' found 'b8:16' claiming '/run/udev/links/\x2fdisk\x2fby-path\x2fpci-0000:01:00.0-ata-1' creating link '/dev/disk/by-path/pci-0000:01:00.0-ata-1' to '/dev/sdb' preserve already existing symlink '/dev/disk/by-path/pci-0000:01:00.0-ata-1' to '../../sdb' created db file '/run/udev/data/b8:16' for '/devices/pci0000:00/0000:00:02.1/0000:01:00.0/ata3/host2/target2:0:0/2:0:0:0/block/sdb' .ID_FS_TYPE_NEW= ACTION=add DEVLINKS=/dev/disk/by-path/pci-0000:01:00.0-ata-1 /dev/disk/by-id/wwn-0x5000c5008b32e037 /dev/disk/by-id/ata-ST2000VN000-1HJ164_W7209GX3 DEVNAME=/dev/sdb DEVPATH=/devices/pci0000:00/0000:00:02.1/0000:01:00.0/ata3/host2/target2:0:0/2:0:0:0/block/sdb DEVTYPE=disk ID_ATA=1 ID_ATA_DOWNLOAD_MICROCODE=1 ID_ATA_FEATURE_SET_APM=1 ID_ATA_FEATURE_SET_APM_CURRENT_VALUE=63 ID_ATA_FEATURE_SET_APM_ENABLED=1 ID_ATA_FEATURE_SET_HPA=1 ID_ATA_FEATURE_SET_HPA_ENABLED=1 ID_ATA_FEATURE_SET_PM=1 ID_ATA_FEATURE_SET_PM_ENABLED=1 ID_ATA_FEATURE_SET_PUIS=1 ID_ATA_FEATURE_SET_PUIS_ENABLED=0 ID_ATA_FEATURE_SET_SECURITY=1 ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=236 ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=236 ID_ATA_FEATURE_SET_SMART=1 ID_ATA_FEATURE_SET_SMART_ENABLED=1 ID_ATA_ROTATION_RATE_RPM=5900 ID_ATA_SATA=1 ID_ATA_SATA_SIGNAL_RATE_GEN1=1 ID_ATA_SATA_SIGNAL_RATE_GEN2=1 ID_ATA_WRITE_CACHE=1 ID_ATA_WRITE_CACHE_ENABLED=1 ID_BUS=ata ID_FS_TYPE= ID_MODEL=ST2000VN000-1HJ164 ID_MODEL_ENC=ST2000VN000-1HJ164\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 ID_PART_TABLE_TYPE=gpt ID_PART_TABLE_UUID=fde78847-0d93-4ab7-bd9c-47d6dff3bf35 ID_PATH=pci-0000:01:00.0-ata-1 ID_PATH_TAG=pci-0000_01_00_0-ata-1 ID_REVISION=SC60 ID_SERIAL=ST2000VN000-1HJ164_W7209GX3 ID_SERIAL_SHORT=W7209GX3 ID_TYPE=disk ID_WWN=0x5000c5008b32e037 ID_WWN_WITH_EXTENSION=0x5000c5008b32e037 MAJOR=8 MINOR=16 SUBSYSTEM=block TAGS=:systemd: USEC_INITIALIZED=5571888 run: '/usr/bin/hdparm -B 63 -S 36 /dev/sdb' run: '/usr/bin/touch /tmp/udev-sdb' Unload module index Unloaded link configuration context. As you can see (near the end), the command /usr/bin/hdparm -B 63 -S 36 /dev/sdb gets executed. The problem is now that the disks won't go into standby after 3 minutes after boot, i.e., the -S 36 option is not applied. However, the APM is set to 63, as a hdparm -B shows. If I login as root after boot and execute the hdparm command above again, the standby timer is set to 3 minutes and the HDDs go indeed into standby as expected. Any ideas why hdparm -S 36 is not applied if run by udev during boot?

How can I keep my external hard drive connected to the USB port but in an unmounted state to preserve it? Is it possible to remount it at any time? I would like to keep it on for just an hour a day for writing and turn it off for the rest of the time. Can hdparm help? I don’t know how to use it.

I'm trying to port some scripts from FreeBSD to Linux so that I can share some management scripts with non-BSD platforms. One script in particular uses mdconfig, and I haven't yet found any Linux tool that matches its capabilities. The script is a generalized ZFS pool constructor that can work with either physical or virtual block devices, creating matching GPT partition tables on each device according to a pre-specified schema, naming the partitions by joining the partition type and the device serial number. So for serial numbers AAAA1111 WXYZJ97 and 7JN52XH19 and partition types EFI, SWAP and ZFS, the three disks will be partitioned identically with partitions named: EFI-AAAA1111 SWAP-AAAA1111 ZFS-AAAA1111 EFI-WXYZJ97 SWAP-WXYZJ97 ZFS-WXYZJ97 EFI-7JN52XH19 SWAP-7JN52XH19 ZFS-7JN52XH19 and the Zpool will be built from the ZFS-* partitions, depending on how the user lays out the config file that specifies such things. mdconfig creates a file-, memory- or swap-backed (or even bit-bucket-backed) block device, which is transparently indistinguishable from a real hard drive,\* or most any other block device (swap partition, tape drive, etc.), and tools based on FreeBSD's GEOM framework interface seamlessly with either physical or virtual block devices, to query device properties like size, sector count, sector size, device serial number, etc. # truncate -s10G disk.img # mdconfig disk.img md0 # gpart create -s gpt /dev/md0 md0 created # gpart show -l /dev/md0 => 40 20971440 md0 GPT (10G) 40 20971440 - free - (10G) # diskinfo -v /dev/md0 /dev/md0 512 # sectorsize 10737418240 # mediasize in bytes (10G) 20971520 # mediasize in sectors 0 # stripesize 0 # stripeoffset MD-DEV94492983848663588-INO6048 # Disk ident. Yes # TRIM/UNMAP support Unknown # Rotation rate in RPM When testing and experimenting, it's frequently convenient to be able to utilize virtual block devices just as though they were physical devices, without requiring a lot of what's and if's and special cases in my code. The serial number ("Disk ident.") of the drive -- whether physical or virtual -- is pivotal in the naming of the GPT partitions, and the GPT partition names in turn become part of the ZFS vdev structure. Then if a device fails, I can quickly identify it because the serial number is printed directly on the drive label (and sometimes hand-labeled on the drive tray as well, for hot-swappable backplanes). While device failure isn't a common scenario with virtual devices, the point is to have flexible tools with a unified interface that don't need to be rewritten when switching from using virtual devices to physical, or indeed, a mix. So far I have been experimenting with losetup on Linux. sfdisk can understand the virtual devices it creates, but hdparm cannot, nor can sdparm. hdparm is the primary tool I'm aware of that can report a device's serial number on Linux. # hdparm /dev/loop1 /dev/loop1: readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Inappropriate ioctl for device # sdparm /dev/loop1 unable to access /dev/loop1, ATA disk? Lacking access to the serial number, I've been relying on a rather ugly hack to use the GPT UUID: # $1 is device, what's its serial number? if freebsd then # Easy: SN="$( diskinfo -v "$1" | awk '/Disk ident\./ {print $1; exit}' )" else # Not so easy: partprobe "$1" >/dev/null 2>&1 udevadm="$(udevadm info "$1")" diskinfo="$( egrep " ID_SERIAL_SHORT=" \*: By that I mean that, although strictly speaking, one *can* distinguish between the two, I haven't found any FreeBSD tools that work on real drives but break when used on virtual drives.

I'd like to set the idle timeout of a hybrid-SSD/HDD and am surprised to read the Arch Wiki saying to install *hdparm* as the starting point to set disk software settings. Does that mean some distributions are set in some way but don't provide the mean to control it? Or that in 2024 other tools have replaced *hdparm*, then why is *hdparm* the first result appearing?

I use sudo hdparm -W 0 /dev/sdb to disable the write cache for the HDD, and the information `/dev/sdb: write-caching = 0 (off)` shows that the write cache is truly off. But when I use the instruction sudo dmesg it shows that:

[23361.915713] sd 32:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

I see the write cache is still enabled, I would like to know how to truly disable the write cache function (in dmesg) in Ubuntu for an external HDD.

I have an old mSATA SSD (model name: Plextor PX-128M6M), which is installed to an mSATA-to-USB enclosure with ASM1153E controller. I want to *(just logically, at the SSD controller level)* erase all of its data. However, it seemed that: 1. blkdiscard command does not actually erase all requested region of data, just the beginning 2GiB minus 32KiB of data was actually erased. 2. hdparm --trim-sector-ranges-stdin seems to work fine, however, the SSD controller *(of this model of SSD specifically, another model does not seem to behave like this)* seems to be protecting the first 8 sectors (4KiB of data) from being erased by TRIM command. -------- My attempts and experiments are as follows: 1. I was doing this under Ubuntu 23.04. 2. Thanks to the guides from Arch Wiki, I found that I have to set /sys/block/sdX/device/scsi_disk/*/provisioning_mode to unmap first. It was full initially. After that, I thought the system was then able to send SCSI UNMAP command (through UASP, translated into TRIM command by the controller) to the old SSD. 3. I then did this to the whole drive: blkdiscard -f -v /dev/sdX (sdX is the actual device name), it then reported that all bytes (matches with the disk capacity) was discarded (erased), however I found that both the main GPT and the backup GPT at the beginning/end of disk space were still not erased. 4. I created a partition sized 2GiB, and then filled it with random data drained from /dev/urandom. 5. blkdiscard -f -v /dev/sdX was done on the whole drive, hexdump then showed that the last 1MiB + 32KiB of the first partiton was not erased (the partition starts from LBA 2048, with a sector size of 512 Bytes). 6. After re-executing blkdiscard -f -v /dev/sdX1 on the new partition instead of the whole drive, hexdump showed that the last 32KiB of this partition was not erased. 7. I then tried hdparm --trim-sector-ranges-stdin, with a list of all sectors of the whole drive fed from stdin. This time the main GPT still stood, but all remaining data was erased to zero. 8. I filled the first 2048 sectors with /dev/urandom data. Then hdparm --trim-sector-ranges-stdin seemed to erase all data except the first 8 sectors (4KiB of data). -------- To confirm that the behavoir of first 8 sectors not being erased is enforced by the SSD controller instead of mSATA-to-USB chip: 9. I then installed this old Plextor SSD as an internal mSATA drive without USB enclosure. The first 8 sectors still survived after hdparm --trim-sector-ranges-stdin. 10. I have another newer Kingston-branded mSATA SSD. I tested it with hdparm --trim-sector-ranges-stdin, but all sectors went zero without one single exception, no matter it's USB-enclosed or directly installed as an internal drive.

I am trying to interpret this result of hdparm: janus@behemoth ~ $ sudo hdparm -Tt --direct /dev/nvme0n1 /dev/nvme0n1: Timing O_DIRECT cached reads: 2548 MB in 2.00 seconds = 1273.69 MB/sec Timing O_DIRECT disk reads: 4188 MB in 3.00 seconds = 1395.36 MB/sec I do not understand how the cached reads can be slower than the direct disk reads. If I drop the --direct, I get what I would have expect: the disk reads are slower than the cached ones: janus@behemoth ~ $ sudo hdparm -Tt /dev/nvme0n1 /dev/nvme0n1: Timing cached reads: 22064 MB in 2.00 seconds = 11042.86 MB/sec Timing buffered disk reads: 2330 MB in 3.00 seconds = 776.06 MB/sec (Although it says "buffered disk reads" now). Can somebody explain to me what is going on?

Apparently, hdparm only works with internal HDD's.
How do I avoid an external HDD from spinning down after half a minute? One way is to read one sector using badblocks or dd each 29 seconds in an infinite loop. Is there another way to keep the HDD spinning? Edit: SMART is also not supported by that HDD. hdparm -y also does not work, but works for a different external HDD.

i installed new debian 9.8 server for DB application.it has two disk and running on vCenter 6.0. First write disk write speed 100-120 Mb/sec suddenly after for while disk write speed decrease drastically to 1-5 Mb/sec. - i change datastore totaly different storage- same problem continued i - updated kernel to new one(5.0.14) nothing happened - i added *no barrier=0 noatime* on fstab; same problem continued - umount disk and fsck ; same problem continued this mount output; sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=32686212k,nr_inodes=53329,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=6539196k,mode=755) /dev/mapper/DPADBSRV1--vg-root on / type ext4 (rw,noatime,nobarrier,errors=remount-ro) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12165) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) mqueue on /dev/mqueue type mqueue (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) /dev/sdb1 on /data type ext4 (rw,noatime,nobarrier) /dev/sda1 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=2344888k,mode=700,uid=1000,gid=1000) This is the dd wirte test within one hour period. 134217728 bytes (134 MB, 128 MiB) copied, 1.34163 s, 100 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 1.43202 s, 93.7 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 1.40082 s, 95.8 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 1.31636 s, 102 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 1.39147 s, 96.5 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 1.81849 s, 73.8 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1G count=1 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.4479 s, 65.3 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 1.40814 s, 95.3 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 9.36281 s, 14.3 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 3.23355 s, 41.5 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 35.4718 s, 3.8 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 33.546 s, 4.0 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 61.1867 s, 2.2 MB/s root@DP1:/home/debian# dd if=/dev/zero of=tempfile bs=1M count=128

When I want Linux to consider newly created partitions without rebooting, I have several tools available to force a refresh of the kernel "partition cache": - partx -va /dev/sdX - kpartx -va /dev/sdX - hdparm -z /dev/sdX - blockdev --rereadpt /dev/sdX - sfdisk -R /dev/sdX (deprecated) - partprobe /dev/sdX - ... I'm not sure about the difference between these techniques, but I think they don't use the same ioctl, like BLKRRPART or BLKPG. So, **what is the difference between those ioctl?**

To use hdparm's --security-erase, I need to provide a password; and for that to work, I need to first set a password. Why is that? i.e. if I've never set a security password for my drive, why wouldn't the secure erase functionality just work with no password specified?

I was thinking about to let hd-idle manage the spin down of all my drives after 3 hours because I am having trouble doing so with hdparm or smartctl in conjunction with apm or sleep command. ___ So my question is: Does HD-Idle check if the disk is in use or idle prior to send it to sleep? And in case it does not: Do you have a nice solution or script that I can copy / modify to my needs?

I have conf for hdparm: /etc/hdparm.conf apm = 127 force_spindown_time = 120 /dev/sda { apm = 127 acoustic_management = 128 spindown_time = 120 } /dev/sdb { apm = 127 acoustic_management = 128 spindown_time = 120 } But **hdparm -S** show missing value root@DietPi:~# hdparm -S /dev/[sh]d[a-z] -S: bad/missing standby-interval value (0..255) If I run command to enable it - everything seems ok, but no. Settings does not apply: root@DietPi:~# hdparm -S 120 /dev/sda /dev/sda: setting standby to 120 (10 minutes) root@DietPi:~# hdparm -S /dev/sda -S: bad/missing standby-interval value (0..255) root@DietPi:~# hdparm -B /dev/sda /dev/sda: APM_level = 127 root@DietPi:~#

My WD6400AAKS is attached to a Raspberry by USB. It is contained in an external USB-case with access LED. It works fine on hdparm -y and spins down. If you do an ls on that drive, it spins up. So far so good. Unfortunately it doesn't recognize -S. Tried -S 1, -S 12. hdparm returns correctly with no error, but drive won't spin down, though no access is indicated by LED. Any idea?

My setup: Raspberry 4 / Raspberry OS; additional 3TB WD HDD attached via USB3 I was using hdparm to spin down this harddisk after 3o min. This **was working perfectly fine** until few days ago. Now, there was a power outage that caused the raspi to reboot, and since then the hdparm command just stopped working. Here is the output:

root@raspi:/ # hdparm -S /dev/sdb
  -S: bad/missing standby-interval value (0..255)
	
root@raspi:/ # hdparm -S 36 /dev/sdb
/dev/sdb:
 setting standby to 36 (3 minutes)
 
root@sraspi:/ # hdparm -S /dev/sdb
  -S: bad/missing standby-interval value (0..255)

The drive is not spinning down after 3 min. Smartmontools say the disk is healthy, also some samba shares on the disk work fine. And like I said, before the power outage and forced reboot all was ok. Anybody has an idea what's the problem here??? **Update:** I tried to use sdparm, result:

root@raspi:/ # sdparm --all /dev/sdb
    /dev/sdb: asmedia   ASM1153E          0   
Write parameters (MMC) mode page:
  BUFE          0  [cha: n, def:  0, sav:  0]
root@raspi:/ #

This is very weird for me again: 1. it says ASM1153E, which is my USB controller, but wasn't sdparm supposed to talk directly to the harddisk??? 2. there are parameters missing, especially SCT and STANDBY which I intended to use (maybe because of 1.??) Any help or thoughts are very appreciated

I have a mdadm RAID 1 of two Toshiba MG09 18Ts in my pc but I don't need to access them very often, maybe 1-2 times a week. I'm booting the pc once per day which also spins up the hdds. When using a systemd service to put the drives to sleep right after boot they sleep until they are accessed, or, and thats one part that annoys me, when I'm shutting down. Is there a way to prevent spinning up on shutdown? I have also read about a SATA feature called "power up in standby" / PUIS to not spin up the drives on boot but from the hdparm -s description I'm unsure whether I could actually use this. Using the latest kernel the OS should support this feature. But I couldn't find any info on whether the drives or my mainboard (Crosshair VI Hero) support it. Is there a way to safely check if this feature is supported?

With a non-NVMe drive, I can run: # hdparm -I /dev/whatever | grep TRIM Data Set Management TRIM supported (limit 8 block) Deterministic read data after TRIM With a Samsung 960 EVO 1TB NVMe drive (PCI Express), I get: # hdparm -I /dev/nvme0n1 /dev/nvme0n1: HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device I can run # smartctl --all /dev/nvme0n1 And get some information about the drive, but nothing about TRIM type. I installed nvme-cli, and ran nvme get-feature -f 0 to -f 0xe and got some features from the drive, but nothing about TRIM type. Is there a way in Linux to query an NVME device, to list what type of TRIM it supports? Is there a way in Linux to query an NVMe device, to get a list of anything else hdparm -I would show if it weren't an NVMe, that smartctl and nvme don't seem to cover?

Does anyone know of a clever way to receive any sort of progress status updates using hdparm secure erase? Ideally the end result would be something like dd's status=progress attribute.

I've got an external ssd that was giving me Transport endpoint is not connected errors after a few hours of a lengthy rsync I was doing. So I set the 'advanced power options' to never power-off : jeremy@jeremy-Blade:~$jeremy@jeremy-Blade:~$ sudo hdparm -B 0 /dev/sg0 [sudo] password for jeremy: /dev/sg0: setting Advanced Power Management level to 0x00 (0) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 APM_level = not supported which as far as I can tell fixed that problem (at least the rsync completed subsequently, despite the 'APM_level = not supported' caveat). However when I run some checks to see if the rsync was largely successful, I hit 'software caused connection abort' and then the transport endpoint err again, with disk no longer mounted: jeremy@jeremy-Blade:~$ find /media/jeremy/JR_SSD/tms/ -type f |wc -l find: ‘/media/jeremy/JR_SSD/tms/20140221/images’: Software caused connection abort find: ‘/media/jeremy/JR_SSD/tms/20140222’: Transport endpoint is not connected .... So my question is what's gone wrong, and/or how to avoid this 'software caused connected abort' business. None of the other SO threads on this err seem relevant. There should be around 30 million files found by the find, taking 350Gb, if that makes any difference. edit df -T lists the ssd as type:fuseblk, internal hd is type:ext4