On 03.05.22 20:50, Eric Blake wrote:
On Tue, May 03, 2022 at 04:55:29PM +0200, Hanna Reitz wrote:
Add some (optional) information that the file driver can provide for
image files, namely the extent size.
Signed-off-by: Hanna Reitz <hre...@redhat.com>
---
qapi/block-core.json | 26 ++++++++++++++++++++++++--
block/file-posix.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 2 deletions(-)
+++ b/block/file-posix.c
@@ -3068,6 +3068,34 @@ static int raw_get_info(BlockDriverState *bs,
BlockDriverInfo *bdi)
return 0;
}
+static ImageInfoSpecific *raw_get_specific_info(BlockDriverState *bs,
+ Error **errp)
+{
+ BDRVRawState *s = bs->opaque;
+ ImageInfoSpecificFile *file_info = g_new0(ImageInfoSpecificFile, 1);
+ ImageInfoSpecific *spec_info = g_new(ImageInfoSpecific, 1);
+
+ *spec_info = (ImageInfoSpecific){
+ .type = IMAGE_INFO_SPECIFIC_KIND_FILE,
+ .u.file.data = file_info,
+ };
+
+#ifdef FS_IOC_FSGETXATTR
+ {
+ struct fsxattr attr;
+ int ret;
+
+ ret = ioctl(s->fd, FS_IOC_FSGETXATTR, &attr);
+ if (!ret && attr.fsx_extsize != 0) {
+ file_info->has_extent_size = true;
+ file_info->extent_size = attr.fsx_extsize;
+ }
+ }
+#endif
Can/should we fall back to stat's st_blksize when the ioctl produces
nothing?
I don’t think so, that’s a different value. For example, by default, we
use an extent-size-hint of 1 MB for new images (which is applied at
least on XFS), but that doesn’t change st_blksize (which is 4096 here).
So I’d only report the extent-size for filesystems that actually
differentiate between the two.
Hanna