On Fri, Feb 25, 2011 at 01:49:33PM +0100, Lukas Czerner wrote: > This commit adds QCOW2 support for e2fsck. In order to avoid creating > real QCOW2 image support, which would require creating a lot of code, we > simply bypass the problem by converting the QCOW2 image into raw image > and than let e2fsck work with raw image. Conversion itself can be quite > fast, so it should not be a serious slowdown. > > Add '-Q' option to specify path for the raw image. It not specified the > raw image will be saved in /tmp direcotry in format > <qcow2_filename>.raw.XXXXXX, where X chosen randomly. > > Signed-off-by: Lukas Czerner <lczerner@xxxxxxxxxx> If we're just going to convert the qcow2 image into a raw image, that means that if someone sends us a N gigabyte QCOW2 image, it will lots of time (I'm not sure I agree with the "quite fast part"), and consume an extra N gigabytes of free space to create the raw image. In that case, I'm not so sure we really want to have a -Q option to e2fsck. We might be better off simply forcing the use of e2image to convert the image back. Note that the other reason why it's a lot better to be able to allow e2fsck to be able to work on the raw image directly is that if a customer sends a qcow2's metadata-only image from their 3TB raid array, we won't be able to expand that to a raw image because of ext2/3/4's 2TB maximum file size limit. The qcow2 image might be only a few hundreds of megabytes, so being able to have e2fsck operate on that image directly would be a huge win. Adding iomanager support would also allow debugfs to access the qcow2 image directly --- also a win. Whether or not we add the io_manager support right away (eventually I think it's a must have feature), I don't think having a "decompress a qcow2 image to a sparse raw image" makes sense as an explicit e2fsck option. It just clutters up the e2fsck option space, and people might be confused because now e2fsck could break because there wasn't enough free space to decompress the raw image. Also, e2fsck doesn't delete the /tmp file afterwards, which is bad --- but if it takes a large amount of time to create the raw image, deleting afterwards is a bit of waste as well. Probably better to force the user to manage the converted raw file system image. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
