So do we say its how the tool has to behave? (surely with added documentation) On Wed, Mar 7, 2018 at 10:38 AM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: > I'd say it's something that could be better documented (size as > percentage rounds to the minimum blocksize) in the same way it's > already documented for offset percentages. The problem is if size > didn't do the rounding of percentages things would get tricky when you > start trying to cut disks up using offset and size (think offset=0% > size=25% then offset=25% size=25%). Plus you don't really want to do > rounding when the user specifies an exact amount/doesn't set anything > at all because you want to assume the user knows what they are > doing... > > On 7 March 2018 at 18:14, abhishek koundal <akoundal@xxxxxxxxx> wrote: >> Hi >> Yes that is correct. The drive is showing : >> 2000398934016 and its not exact multiple of 128K >> >> So do we think this is how the tool will behave or we have a bug here? >> >> On Wed, Mar 7, 2018 at 12:17 AM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: >>> Hi, >>> >>> What does >>> blockdev --getsize64 /dev/nvme0n1 >>> say? I'm going to guess that whatever number comes out is not an exact >>> multiple of 128Kbytes... > > -- > Sitsofe | http://sucs.org/~sits/ -- Life is too short for silly things so invest your time in some productive outputs!! -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
