Does anyone know if there is an elegant way to tell an external usb drive not to spin down after a period of inactivity? I've seen cron based solutions that write a file every minute, but nothing that smells of nice unixey elegance. There must be a hdparm, or scsi command that I can issue (usb drives are accessed via the sd driver in OpenBSD) to the drive to tell it to not sleep. I'm afraid that this is probably a *feature* built into the controller in the enclosure, and as such not much can change it aside from ripping the drive out of it's enclosure and plopping it directly in the machine, but I figured I would ask, on the off chance. Ideally, I'm looking for an OpenBSD solution, but I know there are others out there w/the same problem so any solutions will be considered for the answer.

I want to detect silent corruption of block devices similar to how BTRFS does that for files. I'd even like to do that below BTRFS (and disable BTRFS's native checksumming) so that I can tweak more parameters than BTRFS allows. DM-Integrity seems like the best choice and in principle it must be doing the same thing as BTRFS. The problem is that it's incredibly, unusably slow. While sequential writes on BTRFS are 170+ MiB/s (with compression disabled), on DM-Integrity they're 8-12 MiB/s. I tried to match DM-Integrity parameters with BTRFS (sector size, hashing algorithm, etc) and I tried lots of combinations of other parameters (data interleaving, bitmapping, native vs generic hashing drivers, etc). The writes were asynchronous, but the speed was calculated based on the time it took for writes to be committed (so I don't think the difference was due to memory caching). Everything was on top of a writethrough Bcache, which should be reordering writes (so I don't think it could be BTRFS reordering writes). I can't think of any other reason that could explain this drastic performance difference. I'm using Debian 11 with a self-compiled 6.0.12 Linux kernel and sha256 as my hashing algorithm. My block layers are (dm-integrity or btrfs)/lvm/dm-crypt/bcache/dm-raid. **Is there a flaw in my testing? Or some other explanation for this huge performance difference? Is there some parameter I can change with DM-Integrity to achieve comparable performance to BTRFS?**

I use LUKS (so my system is encrypted) and LVM. I don’t want sda displayed because that’s where my root filesystem lives, and it’s my root device. The solution should also work for systems without LUKS or LVM, meaning it must handle all scenarios. I'm on a Debian 12.x and I want to display all main devices in a one row command, if possible, ***except my root device***, regardless of whether it's an LVM, LUKS or not, etc. The command should be flexible, and I don’t want to use fixed specifications *--vg-root, etc., if possible. > **@bertieb comment:** From the added output, it seems the root mountpoint is in a volume group in an encrypted volume on the device is presenting itself as sda -- OP wants that entire device and all associated block 'devices' elided ? i.e. remove root vg AND swap, crypt, containing partition (sda3) plus other partitions, and finally the device (sda) And that should be my result, ***so all main devices without*** sda because that’s my root device where my root filesystem is /, and without me having to specify details, so I can use it on other **devices/systems** as well, whether LVM, LUKS, etc., without needing to know what root is called, or what the UUID is, etc. I don't want to see the partitions too, only the main devices without root device, like in this command lsblk -d -o NAME,SIZE --sort SIZE. This is the output I need: - No sda (since it's the root device containing my root filesystem /) - Only main devices displayed (regardless of how many exist) - No partitions included from the other devices ##### RESULT I NEED :

NAME     SIZE
nvme0n1  238.5G

**My Setup:**

$ lsblk -d -o NAME,SIZE --sort SIZE
NAME      SIZE
sda      57,3G
nvme0n1 238,5G

$ lsblk -fs -o NAME
# ROOT DEVICE
sda1
`-sda
sda2
`-sda
desktop--vg-root
`-sdb3_crypt
  `-sda3
    `-sda
...
...

$ lsblk
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                    8:0    1  57,3G  0 disk  
├─sda1                 8:1    1   512M  0 part  /boot/efi
├─sda2                 8:2    1   488M  0 part  /boot
└─sda3                 8:3    1  56,3G  0 part  
  └─sdb3_crypt       254:0    0  56,3G  0 crypt 
    ├─desktop--vg-root   254:1    0  55,3G  0 lvm   /
    └─desktop--vg-swap_1 254:2    0   980M  0 lvm   [SWAP]
nvme0n1              259:0    0 238,5G  0 disk  
└─nvme0n1p1          259:1    0 238,5G  0 part  /user/backup

I don't want that, for example /dev/mapper/desktop--vg-root,sdb3_crypt, sda3 no sda. But rather this here from the example sda, this is the root device, so I don't need this device in the output. #### MY DEVICES, MY SETUP:

NAME           SIZE      
sda            57.3G     
|-sda1         512M      
|-sda2         488M      
`-sda3         56.3G     
`-sdb3_crypt   56.3G     
`-desktop--vg-swap_1980M      
nvme0n1        238.5G    
`-nvme0n1p1    238.5G

**RESULT I NEED:**

NAME     SIZE
nvme0n1  238.5G

##### System setup Debian, lsblk and other information:

Operating System: Debian GNU/Linux 12 (bookworm)  
Kernel: Linux 6.1.0-22-amd64
Architecture: x86-64

lsblk from util-linux 2.38.1

$ apt-get install --only-upgrade util-linux

util-linux is already the newest version (2.38.1-5+deb12u3)

##### From @terdon RESULT:

(){ lsblk -o NAME,SIZE,MOUNTPOINT | awk '$NF!="/"{printf "%-15s%-10s\n", $1,$2}'; }

NAME           SIZE      
sda            57.3G     
|-sda1         512M      
|-sda2         488M      
`-sda3         56.3G     
`-sdb3_crypt   56.3G     
`-desktop--vg-swap_1980M      
nvme0n1        238.5G    
`-nvme0n1p1    238.5G

$ lsblk -o NAME,SIZE,MOUNTPOINT

NAME                   SIZE MOUNTPOINT
sda                   57.3G 
|-sda1                 512M /boot/efi
|-sda2                 488M /boot
`-sda3                56.3G 
  `-sdb3_crypt        56.3G 
    |-desktop--vg-root    55.3G /
    `-desktop--vg-swap_1  980M [SWAP]
nvme0n1              238.5G

$ lsblk -o NAME,SIZE,MOUNTPOINT | awk '$NF!="/"{printf "%-15s%-10s\n", $1,$2}';

NAME           SIZE      
sda            57.3G     
|-sda1         512M      
|-sda2         488M      
`-sda3         56.3G     
`-sdb3_crypt   56.3G     
`-desktop--vg-swap_1980M      
nvme0n1        238.5G

$ lsblk -o NAME,SIZE,MOUNTPOINT | awk '$NF=="/"' |-desktop--vg-root 55.3G / ##### From Chris Davies RESULT:

Root partition: mapper/desktop--vg-root
Root device: 
NAME      SIZE
sda      57.3G
nvme0n1 238.5G

##### From @muru: lsblk -d $(findmnt -no source /)

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
desktop--vg-root 254:1    0 55,3G  0 lvm  /

Is it possible to pvcreate a pv by any more unique means than the standard "/dev/sdX"? The reason is the external multiple hard drive dock and dev mapper on my system don't always assign the same "/dev/sdX" at boot. I work around this with ext4 mounts in fstab by mounting by uuid, otherwise the results could be disastrous reads/writes to the wrong disk.

Finding offset of a filesystem that resides directly on a partition is easy: check the partition start sector, multiply by sector size, done. What if the filesystem lives inside LVM? I could scan the drive for its distinctive features like the magic number, UUID, etc., but I'm thinking of something that doesn't rely on matching by content. Is there a generalized solution for all kinds of block devices? What about those that don't store data literally, like for example LUKS containers, dm-integrity and such? I don't think block devices form any kind of hierarchy, so I guess the answer is no?

I am trying to understand how data is written to the disk. I'm writing data with dd using various block sizes, but it looks like the disk is always getting hit with the same size blocks, according to iostat. For example this command should write 128K blocks. dd if=/dev/zero of=/dev/sdb bs=128K count=300000 Trimmed output of iostat -dxm 1: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0.00 129897.00 0.00 1024.00 0.00 512.00 1024.00 142.09 138.81 0.00 138.81 0.98 100.00 My reading of this is that it's writing 512MBps in 1024 operations. This means each write = 512/1024 = 512K. Another way of calculating the same thing: The avgrq-sz column shows 1024 sectors. According to gdisk the sector size of this Samsung 850 Pro SSD is 512B, therefore each write is 1024 sectors * 512B = 512K. So my question is, why is it writing 512K blocks instead of 128K as specified with dd? If I change dd to write 4M blocks, the iostat result is exactly the same. The merges number doesn't make sense to me either. That was writing directly to the block device; but if I format it XFS and write to the filesystem, the numbers are the same except zero merges: dd if=/dev/zero of=/mnt/ddtest bs=4M count=3000 Now iostat shows Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0.00 0.00 0.00 1024.00 0.00 512.00 1024.00 142.31 138.92 0.00 138.92 0.98 100.00 I'm using RHEL 7.7 by the way.

I'm running Ubuntu 23.10 on a I9 cpu + Nvidia Geforce RTX 2080 ti and the driver 545 right now. Everything works great,but not snap. I've tried to remove it as soon as I have installed Ubuntu from scratch,but something went wrong and now I see the following errors during boot : /var/lib/snapd/snaps/bare_5.snap: Can't open blockdev /var/lib/snapd/snaps/core22_607.snap: Can't open blockdev /var/lib/snapd/snaps/core22_864.snap: Can't open blockdev /var/lib/snapd/snaps/firefox_2517.snap: Can't open blockdev /var/lib/snapd/snaps/firmware-updater_109.snap: Can't open blockdev /var/lib/snapd/snaps/gnome-42-2204_141.snap: Can't open blockdev /var/lib/snapd/snaps/gnome-42-2204_87.snap: Can't open blockdev /var/lib/snapd/snaps/gtk-common-themes_1535.snap: Can't open blockdev /var/lib/snapd/snaps/snap-store_1046.snap: Can't open blockdev /var/lib/snapd/snaps/snap-store_959.snap: Can't open blockdev /var/lib/snapd/snaps/snapd_18933.snap: Can't open blockdev /var/lib/snapd/snaps/snapd_20290.snap: Can't open blockdev /var/lib/snapd/snaps/snapd-desktop-integration_83.snap: Can't open blockdev Anyway,snap seems to work ok (because I've reinstalled it with the purpose to remove it again when I was able to fix the errors) : # snap list Name Version Rev Tracking Publisher Notes core 16-2.60.4 16202 latest/stable canonical✓ core hello-world 6.4 29 latest/stable canonical✓ - What I want to do really is to remove snap totally,including the errors that you see above. I tried different approaches,but none worked,errors keep coming back.

In Ubuntu, I have mounted a raw disk .img file as a loop device that contains a LUKS encrypted LVM with an Ubuntu install on it. It is mounted like so: (output is from lsblk -o NAME,PKNAME,KNAME,FSTYPE,SIZE /dev/loop0

`
NAME                      PKNAME KNAME FSTYPE        SIZE
loop0                            loop0               240G
├─loop0p1                 loop0  dm-11 ext4          487M
├─loop0p2                 loop0  dm-12                 1K
└─loop0p5                 loop0  dm-13 crypto_LUKS 239.5G
  └─cloneluks             dm-13  dm-14 LVM2_member 239.5G
    ├─ubuntuclone-lv_swap dm-14  dm-15                 8G
    └─ubuntuclone-lv_root dm-14  dm-16 ext4        231.5G

` Is there any command that I can use in a script to return the root "block device" (I'm not sure if that's the correct term), when I give the mounted LV name? I was hoping that lsblk -no pkname /dev/ubuntuclone/lv_root would work, but it outputs nothing - using kname gives me dm-16. I want to get to loop0. I also saw [this answer](https://unix.stackexchange.com/a/308724/52247) which implied I could use "$(basename "$(readlink -f /dev/VG/LV)")", but I couldn't work out how to use it:

`
 dev=/dev/ubuntuclone/lv_root ; echo "$(basename "$(readlink -f $dev)")"

` outputs dm-16. I can't work out how to get "past" the crypto_LUKS container. This is what I'm looking for: for input: /dev/ubuntuclone/lv_root or ubuntuclone-lv_root I would like to get output: /dev/loop0 Thanks. edit: I think using lsblk --json | jq might be exactly what I want, but I'm having a lot of trouble working out the correct incantations for jq...

I am thinking on using btrfs for a data volume with many small files. It is unclear, what the doc states about the minimal possible block size. It looks, they and we are on a very different edges of the reality. Their block size ideas are about to *increase* the block size, mine is to decrease it. They want to waste disk space, I want to spare it. I also want to decrease the uneeded discard-rewrite operations on SSD volumes. They seem going so far that their doc is actually *unclear* about the minimal btrfs cluster size. What is it? 4k? 16k? 64k? Can I have, for example, 512 byte blocks?

How can I determine used space of a block device that has no filesystem on it? If it helps, such device is managed via lvm. I understand that the concept of "used space" on a device without filesystem isn't a term, but what I mean by "used space of a block device with no filesystem" is "number of blocks that differ from what was initially allocated when that block device was created". How can I calculate it? Maybe there is some daemon that supports this? Or is my concept of used space of a block device with no filesystem ill-formed and OS / hard-drives / SSD's may write some weird data to the block-device if there is no filesystem which would impact the measurement?

I've been trying to get a "clean" f2fs format on a WD SSD drive. But there is something that bugs me, and I cannot seem to find any specific details on it. When I format the SSD with f2fs: ```none $ sudo mkfs.f2fs -f -d9 -l BlueSSD /dev/sdb1 F2FS-tools: mkfs.f2fs Ver: 1.15.0 (2022-05-13) Info: Disable heap-based policy Info: Debug level = 9 Info: Label = BlueSSD Info: Trim is enabled Info: [/dev/sdb1] Disk Model: NCE0010PNC /dev/sdb1 appears to contain an existing filesystem (f2fs). Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 1953521664 (953868 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 6.12.20+rpt-rpi-v8 (serge@raspberrypi.com) (aarch64-linux-gnu-gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 1:6.12.20-1+rpt1~bpo12+1 (2025-03-19)" Info: [/dev/sdb1] Discarding device Info: This device doesn't support BLKSECDISCARD # This device doesn't support BLKDISCARD This device doesn't support BLKSECDISCARD I found that with both error messages, fstrim would fail. The SSD is connected to my system via USB-SATA adapter cable, so I figured I might need a udev rule. I [found one here](https://glump.net/howto/desktop/enable-trim-on-an-external-ssd-on-linux) that took care of the BLKDISCARD error; i.e. fstrim now runs successfully on the drive. However it did nothing for the BLKSECDISCARD error. [This search](https://duckduckgo.com/?q=what+does+%22BLKSECDISCARD%22+mean&t=ffab&df=2020-04-02..2025-04-03&ia=web) turned up results that suggest this is related to some sort of "security vulnerability" - maybe secure erase/wipe?? The same warning appears in several online posts related to formatting SSDs with mkfs.f2fs, but I've found no discussion or explanation of its meaning. And if it's actually a vulnerability, maybe I should be glad that it's ***not supported*** :) ?? So, a couple of questions for the *cognoscenti*: 1. What is the BLKSECDISCARD message; what does it mean, what are its implications? 2. Is there a patch available that makes it "go away"?

System is Linux Mint 21 based. My USBstick was receiving some files and after message "Do not disconnect" had disappeared I unplugged it. This time though waiting whirl remained in Disks GUI and it remained seen in Nemo. I've tried some naive methods like rm /dev/sdb which did not help. Then I noted when I plug it into USB again, nothing seems to happen. Then I've tried web search and found 1) https://www.reddit.com/r/linuxquestions/comments/vxn53j/how_to_undelete_a_device_file_for_example_devsr0/ And done mknod /dev/sdb b 11 0 mknod /dev/sdb1 b 11 0 echo remove | sudo tee /sys/block/sdb/uevent echo add | sudo tee /sys/block/sdb/uevent echo remove | sudo tee /sys/block/sdb1/uevent echo add | sudo tee /sys/block/sdb1/uevent The result of the above (or just some timeouts), the device no longer seen neither in Disks nor Nemo. But lsblk shows sdb and other web results do not help: https://unix.stackexchange.com/questions/405249/disconnected-block-device-remains-in-dev-sync-commands-unkillable : echo 1 | sudo tee /sys/block/sdb/device/delete > tee: /sys/block/sdb/device/delete: Permission denied ll /sys/block/sdb/device/delete ls: cannot access '/sys/block/sdb/device/delete': No such file or directory journalctl does not add relevant entries (only cron) when I plug-unplug the device, there are entries in /sys, e.g. /sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/host1/target1:0:0/1:0:0:0/block/sdb. What more can I try to get the USBstick working (checked it works in another PC) not to restart the PC? TIA Edit: Before trying out answers: Problematic USBstick and another one do not work in the USB port where the problem appeared. When plugged in another port, Disks GUI does not show them, but lsblk had shown additional sdc, udisksctl mount resulted in Error looking up object for device /dev/sdc1, but sudo mount /dev/sdd1 has worked and the stick can be read and written to. Edit 2 After trying following through the answer by @telcoM: deleting /dev/sdb(1) and re-plugging the stick, then re-creating them mknod with different numbers from the answer: Nothing seems to have changed. Edit 3 I've noted PC wouldn't suspend (maybe because sync hanged up - I run it to physically write all to manually mounted USB stick), then I've lost USB keyboard/mouse connection (connection is loose via a hub and they did not reconnect even in another USB port), so some time later I've restarted the computer. Still proper answer is welcome in case of future similar problems.

I want to clopy a partition between SSD devices. Normally I could do it simply with the "dd" or "buffer" commands. However, now that I have SSDs, I also would like to miss the unneeded writes. *I want all all-zero blocks handled as trimmed blocks.* Is there, ideally a command line tool, to do that?

i would like to fully understand the (special?) handling of eMMC boot partitions (in Linux). As far as i understand, eMMCs offer some kind of low level partitioning. There is a special meaning to (at least) 2 areas: BOOT and RPMB. BOOT leads typically to device nodes like that: /dev/mmcblk1boot0 or /dev/mmcblk1boot1 RPBM usually gives device nodes like this: /dev/mmcblk1rpmb but i am not interested in those RPMB partitions atm. (fyi: interesting article about those can be found here: https://sergioprado.blog/rpmb-a-secret-place-inside-the-emmc/) Those partitions **can be** but **don't have to** be used for the actual boot process itself. While working on upgrading a legacy project (Linux Kernel 3.12) it turns out that in the past those boot partitions could just be used like any other device. So someone created a partition table and a filesystem on top of it. That actually works as expected and you could even see those partitions from within a running linux system like this: /dev/mmcblk1boot0p1. Whereas with a more recent system (Linux Kernel 6.1) those partitions are just not visible anymore. Interesting details are: - fdisk is still listing the paritions - partx can see those partitons but not make them available - partitions can not be mounted - using the blkdevparts kernel commandline parameter does not seem to help (or i used it wrong ^^) It feels like the new system is behaving according to standards, even though i can not explicitly find the point the is forbidding to have a normal partition table within those parts of the eMMC. Or maybe i am just doing smth wrong and those partitions can be mounted somehow. Physically they are still existing. I noticed that in more recent versions of Linux, those boot partitions are write protected. The idea seems to be, to prevent anyone from accidentally breaking a system. Also i know that this can be changed during runtime by simply writing a 0 to the force_ro in the sysfs echo "0" > /sys/class/block/mmcblk1boot0/force_ro. But in this situation there is some actual data stored within those partitions, and it is not needed for the boot process, but very well needed during system runtime. My questions here are: - what changed over that time? - is this intended behavior? - is there any way to still make those partitions available? any hint or clarification on that topic would be very helpful and very much appreciated. thx Christian

Reading through [this tutorial](https://linux-kernel-labs.github.io/refs/heads/master/labs/block_device_drivers.html) and [this reference](https://lwn.net/Articles/552904/) , I see that block device requests go through the hardware queue before being dispatched to the queue_rq handler. When writing a block device driver with only a single hardware queue (configured with nr_hw_queues = 1), can the queue_rq handler still be called from multiple threads simultaneously? It seems to me that a single hardware queue would mean that calls to queue_rq would be implicitly synchronized by the single hardware queue. Is this the case, or can this handler be called from multiple threads simultaneously, even with only a single hardware queue? If possible, a code reference demonstrating the behavior would be much appreciated. Cheers!

I am trying to create partition of SD card, for this I am following this tutorial . When I type the command ll /dev/mmcblk* I got this ls: cannot access /dev/mmcblk*: No such file or directory So, I check the list of items in /dev by typing this command ls /dev/ I got a big list of items but there is nothing like mmcblk0 or mmcblk1. The list I am getting is this autofs dvdrw loop4 psaux ram6 sdb tty10 tty24 tty38 tty51 tty8 ttyS2 ttyS5 vcs6 block ecryptfs loop5 ptmx ram7 sdb1 tty11 tty25 tty39 tty52 tty9 ttyS20 ttyS6 vcs7 bsg fb0 loop6 pts ram8 sg0 tty12 tty26 tty4 tty53 ttyprintk ttyS21 ttyS7 vcsa btrfs-control fd loop7 ram0 ram9 sg1 tty13 tty27 tty40 tty54 ttyS0 ttyS22 ttyS8 vcsa1 bus full loop-control ram1 random sg2 tty14 tty28 tty41 tty55 ttyS1 ttyS23 ttyS9 vcsa2 cdrom fuse mapper ram10 rfkill shm tty15 tty29 tty42 tty56 ttyS10 ttyS24 uhid vcsa3 cdrw hidraw0 mcelog ram11 rtc snapshot tty16 tty3 tty43 tty57 ttyS11 ttyS25 uinput vcsa4 char hpet mei ram12 rtc0 snd tty17 tty30 tty44 tty58 ttyS12 ttyS26 urandom vcsa5 console input mem ram13 sda sr0 tty18 tty31 tty45 tty59 ttyS13 ttyS27 v4l vcsa6 core kmsg net ram14 sda1 stderr tty19 tty32 tty46 tty6 ttyS14 ttyS28 vcs vcsa7 cpu log network_latency ram15 sda2 stdin tty2 tty33 tty47 tty60 ttyS15 ttyS29 vcs1 vga_arbiter cpu_dma_latency loop0 network_throughput ram2 sda3 stdout tty20 tty34 tty48 tty61 ttyS16 ttyS3 vcs2 vhost-net disk loop1 null ram3 sda4 tty tty21 tty35 tty49 tty62 ttyS17 ttyS30 vcs3 video0 dri loop2 port ram4 sda5 tty0 tty22 tty36 tty5 tty63 ttyS18 ttyS31 vcs4 zero dvd loop3 ppp ram5 sda6 tty1 tty23 tty37 tty50 tty7 ttyS19 ttyS4 vcs5 I have followed this tutorial before but I do not any idea what's wrong this time. So,please tell how to get mmcblk list.

For one of my applications, I have to understand the the SATA device driver flow. As per my understanding, SATA device driver should be there in the Linux kernel tree. I have referred how to find the driver module associated with a device on Linux to find the device driver for the SATA device. $ readlink /sys/block/sda/device/driver ../../../../../../../bus/scsi/d I have go to the above location but haven't found a device driver file. usr@usr:/sys/bus/scsi/drivers/sd$ ll total 0 drwxr-xr-x 2 root root 0 Dec 9 17:00 ./ drwxr-xr-x 4 root root 0 Dec 9 17:00 ../ lrwxrwxrwx 1 root root 0 Dec 9 17:47 2:0:1:0 -> ../../../../devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:1/2:0:1:0/ --w------- 1 root root 4096 Dec 9 17:47 bind --w------- 1 root root 4096 Dec 9 17:47 uevent --w------- 1 root root 4096 Dec 9 17:47 unbind usr@usr:/sys/bus/scsi/drivers/sd$ Please suggest how can I see the device driver which was actually load for SATA hard drive on my system.

I want to know what the easiest way is to determine (without root privilege) whether a block device (say sdb) or any part of it is mounted (and which part of it). Checking /proc/mounts for sdb is not enough because sdb or one of its partitions may be used by LVM. You can check /sys/block/sdb/sdb*/holders/ but you get dm-x entries which have to be resolved to /dev/mapper names in order to check /proc/mounts. Possible but if there is an easier solution... (which should not require root privilege)

I tried copying some browser cache files to a separate disk and although the free space was enough the disk run out of space because each small file used took up the minimum disk allocation space. Is there a tool that change the block size without having to copying the files out, reformatting the disks then copying the files back?

I have a small bootable system which requires access to storage devices, but not at the data level (i.e. just firmware commands), with the exception of a USB floppy drive whose data is accessed raw (no filesystem, just dd). Problems are generated from this behaviour as: - Some storage devices are locked which causes firmware errors when read operations are attempted - The seeking of the USB floppy is not required and prolongs the boot process I've tried the following commands:

systemctl disable systemd-udev-trigger.service
systemctl disable systemd-udevd.service

systemctl mask systemd-udev-trigger.service
systemctl mask systemd-udevd.service

systemctl stop systemd-udev-trigger.service
systemctl stop systemd-udevd.service

This however results in no block device being created upon the connection of any devices. I understand that udisks2 may once have been used, however it is not present on my particular system. It looks like blkid might be responsible for the access of block devices as I read that it attempts to "locate/print block device attributes". If this is the cause then I'm unsure how to disable it. Solutions requiring hardcoding of block devices (e.g. /dev/sda) are not possible as I don't know what designation the devices be given. It looks like this question may be related to the issue(s) I'm having, but its solutions involve kernel modification which, if it's getting into all that, I'd rather just put up with the extra ten or so seconds and irritating repetitive floppy seek noises! How might these read operations be prevented whilst still being able to access the device as a block device? Thanks