<jzheng> Do you have any idea why blockdev-setbsz succeeds, but does not affect output of blockdev-getbsz?

<fs> blockdev-getbsz /dev/vda send_to_daemon: 0xf62050 g->state = 3, n = 40 recv_from_daemon: 0xf62050 g->state = 3, size_rtn = 0x7ffffbb4f00c, buf_rtn = 0x7ffffbb4f000 blockdev --getbsz /dev/vda

<fs> blockdev-setbsz /dev/vda 2048 send_to_daemon: 0xf62050 g->state = 3, n = 44 recv_from_daemon: 0xf62050 g->state = 3, size_rtn = 0x7ffffbb4f01c, buf_rtn = 0x7ffffbb4f010 blockdev --setbsz 2048 /dev/vda

<fs> blockdev-getbsz /dev/vda send_to_daemon: 0xf62050 g->state = 3, n = 40 recv_from_daemon: 0xf62050 g->state = 3, size_rtn = 0x7ffffbb4f00c, buf_rtn = 0x7ffffbb4f000 blockdev --getbsz /dev/vda

I can reproduce the same issue too: proc 60 (blockdev_getbsz) took 0.01 seconds 4096 proc 61 (blockdev_setbsz) took 0.01 seconds proc 60 (blockdev_getbsz) took 0.01 seconds 4096 I checked the source of blockdev, and it is using the BLKBSZSET ioctl. As far as I can tell if the ioctl returns an error then blockdev should return an error too (and hence the error should go all the way out to guestfish). So it appears that the Linux kernel is not returning an error. http://lxr.linux.no/#linux+v2.6.35/fs/block_dev.c#L73 The other possibility is that the blockdev --getbsz call is not returning the block size we just set, but that resolves to this call inside the kernel: http://lxr.linux.no/#linux+v2.6.35/include/linux/blkdev.h#L1196 As far as I can see this really ought to work. Perhaps we need to perform some other operation between the two calls, like a udev settle or some sort of rereading block devices ioctl. If this worries you, please file a BZ. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora