[cs615asa] HW4 - AWS Volume Question

Jan Schaumann jschauma at stevens.edu
Wed Mar 20 18:41:17 EDT 2013

kbodzak <kbodzak at stevens.edu> wrote:

> 1) You mention that the -t <tag> option is to specify a volume with the  
> given 'tag'. Does this refer to a volume having a specific tag with key  
> <tag>, or that it has a tag called 'name' with a specific value of  
> <tag>?

Hmm, looks like the semantics for tags has changed since the last time.
Let's say the '-t' flag to our tool specified the *key* of the tag; the
valye of the tag is irrelevant.

It might be useful to assign the current timestamp as the value to the
key whenever a backup is made; that way, a user can easily scan the
volumes and see which one contains the backup from which date.

So suppose no '-t' flag is specified, your program would check if there
is a volume with a tag named 'ec2-backup' (regardless of value).  If one
exists, use that; otherwise, create a new volume and tag is as
'ec2-backup=<timestamp>', where '<timestamp>' would be seconds since the
epoch at the time of command execution (ie "date +%s").

Does that make sense?

> 2) When we are attaching an automatically created volume to a specified  
> instance, are we allowed to assume what type of formatting / mounting  
> procedure should be used and give an error if it is incompatible?

When your tool creates a volume, it would need to make sure to
format/mount as appropriate depending on the chosen backup method.

If a volume was specified (ie a volume with the tag in question exists),
then your program should verify that the format of the volume is
suitable for the backup method.  This mostly boils down to the principle
of least surprise for the user:

- if the user specified 'rsync' as the backup method, but the specified
  volume does not have a file system, don't nuke any possibly existing
  data from that volume -- instead, bail out

- if the user specified 'dd' as the backup method, but the specified
  volume does have a file system, don't nuke the file system -- instead,
  bail out

> 3) If we attempt to ensure that a specified volume has sufficient space  
> for the backup, should we use the same metric we do for creating a new  
> one? (at least 2x as much space as the target directory)

If the volume already exists, then it's probably sufficient if it is
exactly large enough to hold the backup.  Again, this is probably what
the user would expect:  if I want to back up a 1GB directory and know
that I have a 1.2 GB volume, I'd be annoyed if the tool says it can't do
the backup because there's not enough space on the volume.


More information about the cs615asa mailing list