> There's a case for multiplying the return size by the block size of > the filesystem, thus returning the size in bytes. It might make the > API easier to use. Not sure how hard that is, or whether it actually > makes the API easier to use. > > Rich.This multiplication may confuse users who got used to "normal" resize2fs -P behavior (blocks) due to the name of API command. I'm going to implement similar functionality for other filesystems (ntfs, btrfs, xfs). I think we should preserve original command's behavior (well-documented, obviously!) and leave the conversion between blocks, megabytes, etc to user. Maybe (later) we could implement aggregated call (getMinFsSizeInBytes()) to perform all this conversions. -- Your sincerely, Maxim Perevedentsev
Hi, On Wednesday 14 October 2015 12:53:26 Maxim Perevedentsev wrote:> This multiplication may confuse users who got used to "normal" resize2fs > -P behavior (blocks) due to the name of API command. > I'm going to implement similar functionality for other filesystems > (ntfs, btrfs, xfs).Then please implement a single function for all these filesystems, just like set_label, set_uuid, etc. Having to call a different function to get the same information depending on the filesystem is only making artificial barriers in users of the API (which then have to do the function choice at runtime on their own).> I think we should preserve original command's behavior (well-documented, > obviously!) and leave the conversion between blocks, megabytes, etc to user. > Maybe (later) we could implement aggregated call (getMinFsSizeInBytes()) > to perform all this conversions.Please note the API is there also to provide some coherency. -- Pino Toscano
On Wed, Oct 14, 2015 at 06:29:41PM +0200, Pino Toscano wrote:> Hi, > > On Wednesday 14 October 2015 12:53:26 Maxim Perevedentsev wrote: > > This multiplication may confuse users who got used to "normal" resize2fs > > -P behavior (blocks) due to the name of API command. > > I'm going to implement similar functionality for other filesystems > > (ntfs, btrfs, xfs). > > Then please implement a single function for all these filesystems, > just like set_label, set_uuid, etc. Having to call a different function > to get the same information depending on the filesystem is only making > artificial barriers in users of the API (which then have to do the > function choice at runtime on their own). > > > I think we should preserve original command's behavior (well-documented, > > obviously!) and leave the conversion between blocks, megabytes, etc to user. > > Maybe (later) we could implement aggregated call (getMinFsSizeInBytes()) > > to perform all this conversions. > > Please note the API is there also to provide some coherency.I generally agree with Pino that it would be better to have a single API that can handle any filesystem type, and returns the estimated min size in bytes. Note that we can remove and change new APIs until 1.32 (next stable) is released, and after that we keep them forever. I expect to release 1.32 some time in late December 2015. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top