On Fri, Feb 06, 2015 at 04:57:55PM +0900, Teruaki Ishizaki wrote: > (2015/02/06 11:18), Liu Yuan wrote: > >On Wed, Feb 04, 2015 at 01:54:19PM +0900, Teruaki Ishizaki wrote: > >>(2015/02/02 15:52), Liu Yuan wrote: > >>>On Tue, Jan 27, 2015 at 05:35:27PM +0900, Teruaki Ishizaki wrote: > >>>>Previously, qemu block driver of sheepdog used hard-coded VDI object size. > >>>>This patch enables users to handle "block_size_shift" value for > >>>>calculating VDI object size. > >>>> > >>>>When you start qemu, you don't need to specify additional command option. > >>>> > >>>>But when you create the VDI which doesn't have default object size > >>>>with qemu-img command, you specify block_size_shift option. > >>>> > >>>>If you want to create a VDI of 8MB(1 << 23) object size, > >>>>you need to specify following command option. > >>>> > >>>> # qemu-img create -o block_size_shift=23 sheepdog:test1 100M > >>> > >>>Is it possible to make this option more user friendly? such as > >>> > >>> $ qemu-img create -o object_size=8M sheepdog:test 1G > >> > >>At first, I thought that the object_size was user friendly. > >>But, Sheepdog has already the value of block_size_shift > >>in the inode layout that means like object_size. > >> > >>'object_size' doesn't always fit right in 'block_size_shift'. > >>On the other hands, 'block_size_shift' always fit right in > >>'object_size'. > >> > >>I think that existing layout shouldn't be changed easily and > >>it seems that it is difficult for users to specify > >>the object_size value that fit right in 'block_size_shift'. > > > >I don't think we need to change the layout. block_size_shift is what QEMU > >talks > >to sheep, and QEMU options is what users talks to QEMU. We can convert the > >user > >friendly object size into block_size_shift internally in the driver before > >sending it tosheep daemon, no? > > > For example, users specify 12MB for object size, block_size_shift > doesn't fit exactly to an integer.
In this case, we should abort and print the error message and notify the users the acceptable range like erasure coding option. > > I suppose that normally an administrator do format sheepdog cluster > with specifying block_size_shift and users usually do qemu-img command > without a block_size_shift option. block_size_shift is too developer centered and has a direct relation to the underlying algorithm. If in the future, e.g, we change the underlying algorithm about how we represent block size, block_size_shift might not even exsit. So use object_size would be more generic and won't have this kind of problem. Secondly, it is not hard to parse the object_size into block_size_shift, so I'd suggest we'd better try our best to make it user friendly. Thanks Yuan