Should be able to resize s3backer device (maybe already can?)

[GoogleCodeExporter]

Hi,

It really needs to be possible to resize an S3 device. For example, if I create 
a partition now to hold my offsite backup, and then discover in five years that 
I've filled it and need more space, I should be able to simply grow the S3 
device and then run resize_reiserfs or whatever to grow the underlying 
filesystem.

Ditto for shrinking a device.

The s3backer documentation has all kinds of dire warnings about doing this, 
claiming that data won't read back properly if the size of a device is changed, 
but I can't figure out why this is the case.

It seems to me that, as long as the block size isn't changed, if the device is 
grown, more blocks will simply be added on to the end of it.

Shrinking a device is a bit more complicated, since the old files left over 
would need to be cleaned up somehow, but it seems like it should be relatively 
easy to code something to make that happen automatically (coupled with a 
listBlocks) when a filesystem is shrunk.

But aside from the shrinking complication mentioned above, if I'm right that 
it's possible to grow a device simply by increasing its size and then 
specifying "force" the next time you mount, then the documentation should be 
updated to say that, and the warning you get when you mount a filesystem with a 
larger size should be edited to be less dire.

However, the warning should definitely remain dire when the block size is 
changed!

Original issue reported on code.google.com by jikam...@gmail.com on 22 Oct 2010 at 7:26

[GoogleCodeExporter]

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

• Changed state: WontFix
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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