Closed GoogleCodeExporter closed 9 years ago
You can do this if you specify the --force flag and the documentation does
describe it:
--size=SIZE
Specify the size (in bytes) of the backed file to be exported by the filesystem. The size may have an optional
suffix 'K' for kilobytes, 'M' for megabytes, 'G' for gigabytes, 'T' for terabytes, 'E' for exabytes, 'Z' for
zettabytes, or 'Y' for yottabytes. s3backer will attempt to auto-detect the block size by reading block number
zero. If this option is not specified, the auto-detected value will be used. If this option is specified but dis-
agrees with the auto-detected value, s3backer will exit with an error unless --force is also given.
Therefore all you need to do to resize a s3backer disk is run s3backer with
--force --size=NEWSIZE, then read and write back the first block.
Whether this is "safe" depends on what you are storing in the backed file.
E.g., most filesystems won't automatically "notice" the new space so you'd have
to do a separate resize operation for the upper layer filesystem.
Original comment by archie.c...@gmail.com
on 22 Oct 2010 at 7:43
I'm glad to hear that. It is what I figured (as noted above), but like I said,
I don't think the messaging you get from the documentation or the application
is clear, and I think it therefore needs to be updated.
As I noted, when you force a new size on an S3 device, you get a dire warning
about how your data won't read back properly. That's not true at all from the
point of view of the S3 device. If what is meant by all the dire warnings is
that the filesystem built *on top of* the S3 device may have problems, then the
documentation and messages from the program need to be clearer about that,
because there's no way to tell from them that that's what the actual concern is.
And as noted above, you still need to write code to clean extraneous blocks
after shrinking a device.
Thanks,
jik
Original comment by jikam...@gmail.com
on 22 Oct 2010 at 7:50
Original issue reported on code.google.com by
jikam...@gmail.com
on 22 Oct 2010 at 7:26