On Tue, Sep 26, 2017 at 04:14:51PM +0200, Stanislav Brabec wrote:
> @@ -55,6 +56,7 @@ struct loop_info64 {
> uint64_t lo_rdevice;
> uint64_t lo_offset;
> uint64_t lo_sizelimit; /* bytes, 0 == max available */
> + uint64_t lo_blocksize;
> uint32_t lo_number;
> uint32_t lo_encrypt_type;
> uint32_t lo_encrypt_key_size;
See kernel include/uapi/linux/loop.h and the Omars' commit. It does not extend
LOOP_{GET,SET}_STATUS ioctl and loop_info64 struct. All the block size patch is
completely independent ioctl.
> +int loopcxt_get_blocksize(struct loopdev_cxt *lc, uint64_t *blocksize)
> +{
> + struct sysfs_cxt *sysfs = loopcxt_get_sysfs(lc);
> + int rc = -EINVAL;
> +
> + if (sysfs)
> + rc = sysfs_read_u64(sysfs, "queue/logical_block_size", blocksize);
Yes, /sys is fine.
> + if (rc && loopcxt_ioctl_enabled(lc)) {
> + struct loop_info64 *lo = loopcxt_get_info(lc);
> + if (lo) {
> + if (blocksize)
> + *blocksize = lo->lo_blocksize;
> + rc = 0;
> + } else
> + rc = -errno;
This fallback cannot work, because kernel does not provides lo_blocksize by
LOOP_GET_STATUS64. You have to use common BLKSSZGET ioctl.
I'll fix it and ask for review.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
