Support block devices in @-syntax #94

Merged

a-j-wood merged 1 commit from alexanderperlis/pv:support-block-device-size into main

2024-08-06 20:26:44 +00:00

alexanderperlis commented

2024-08-01 00:50:00 +00:00

Contributor

Previously, pv -s @/dev/sda behaved like pv -s 0 because stat on a block device returned a size of 0. Now, additional steps are taken (namely: open device, seek to end) to calculate block device size. Thus, in addition to the prior support for pv -s @<file> there is now also support for pv -s @<device>.

On Linux, instead of seek-to-end, one could use ioctl(..., BLKGETSIZE64, ...), but the seek-to-end approach is presumably more universal, and anyhow was already being used elsewhere in the project, namely in pv_calc_total_bytes() to calculate the size of an output block device.

Previously, `pv -s @/dev/sda` behaved like `pv -s 0` because `stat` on a block device returned a size of 0. Now, additional steps are taken (namely: open device, seek to end) to calculate block device size. Thus, in addition to the prior support for `pv -s @<file>` there is now also support for `pv -s @<device>`. On Linux, instead of seek-to-end, one could use `ioctl(..., BLKGETSIZE64, ...)`, but the seek-to-end approach is presumably more universal, and anyhow was already being used elsewhere in the project, namely in `pv_calc_total_bytes()` to calculate the size of an output block device.

alexanderperlis added 1 commit 2024-08-01 00:50:10 +00:00

Support block devices in @-syntax f6b0ddc0b3

alexanderperlis changed title from ~~WIP: Support block devices in @-syntax~~ to Support block devices in @-syntax

2024-08-01 00:51:46 +00:00

a-j-wood merged commit 4db04564a9 into main

2024-08-06 20:26:44 +00:00

a-j-wood referenced this pull request from a commit

2024-08-06 20:26:44 +00:00

Merge pull request 'Support block devices in @-syntax' (#94) from alexanderperlis/pv:support-block-device-size into main

a-j-wood commented

2024-08-06 20:37:21 +00:00

Owner

Hello, thank you for this.

I did not know about that ioctl() call, but agree that using the same approach as used elsewhere in the code seems reasonable and generic.

Hello, thank you for this. I did not know about that `ioctl()` call, but agree that using the same approach as used elsewhere in the code seems reasonable and generic.

a-j-wood commented

2024-08-06 20:59:28 +00:00

Owner

I did find a snag in that approach, which is that you can't use "--size @/dev/vda" if you don't have read permissions on /dev/vda, whereas "lsblk /dev/vda" works in that case. Following what "lsblk" does using strace suggests a Linux-specific way to get the size by reading from /sys/dev/block/253:0/size where 253:0 is the device's major:minor pair.

So maybe I'll change it a bit. I'm dithering over it because it then means that the command allows something on Linux that it won't on other operating systems, but maybe that's worrying a bit too much. Anyway, either way I'll commit some small changes to this shortly. Thanks again!

I did find a snag in that approach, which is that you can't use "`--size @/dev/vda`" if you don't have read permissions on `/dev/vda`, whereas "`lsblk /dev/vda`" works in that case. Following what "`lsblk`" does using `strace` suggests a Linux-specific way to get the size by reading from `/sys/dev/block/253:0/size` where 253:0 is the device's major:minor pair. So maybe I'll change it a bit. I'm dithering over it because it then means that the command allows something on Linux that it won't on other operating systems, but maybe that's worrying a bit too much. Anyway, either way I'll commit some small changes to this shortly. Thanks again!

alexanderperlis commented

2024-08-07 01:29:42 +00:00

Author

Contributor

My initial thought was that someone would likely only want to use --size @<device> if that same device were either the input or output somewhere else in the chain, implying a strong likelihood of already having read permission. However, with the possibility of virtual devices referring to other devices but with perhaps different permissions (I believe that's the essential aspect of your example), or say there being a write-only device that doesn't allow reading, there evidently could be common situations where one doesn't have read permission yet would still be able to determine the device size via other (perhaps more OS-specific) methods. Supporting that is nice for users who would otherwise by stymied. Even if such support happens initially only for specific systems, that's still a net gain, and doesn't preclude future support for additional systems.

My initial thought was that someone would likely only want to use `--size @<device>` if that *same* device were either the input or output somewhere else in the chain, implying a strong likelihood of already having read permission. However, with the possibility of virtual devices referring to other devices but with perhaps different permissions (I believe that's the essential aspect of your example), or say there being a write-only device that doesn't allow reading, there evidently could be common situations where one doesn't have read permission yet would still be able to determine the device size via other (perhaps more OS-specific) methods. Supporting that is nice for users who would otherwise by stymied. Even if such support happens initially only for specific systems, that's still a net gain, and doesn't preclude future support for additional systems.