On 18 Lis, 20:29, Shapor Naghibzadeh <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 03:37:28AM -0800, szhocker wrote:
> > Hi,
> > I have been testing zumastor since release 0.4 and there is a problem
> > with current release.
> > I've checked zumastor behaviour when overfilling the snapshot space.
> > Data volume size is 20GB and snapshot device size is 1GB.
> > How the test looks like:
> > 1. start zumastor with volume "zumatest" and sizes like said before
> > 2. create 200MB file on volume zumatest
> > 3. take snapshot and check md5 of file in snapshot and on the volume
> > 4. repeate steps 2 and 3 , three more times to have 4 files, each file
> > is 200MB and create one 400MB file
> > 5. After change contents of the first file (it means that space for
> > snapshots is overflow) and taking 5th snapshot and waiting about
> > 1-2min files from 1st taken snapshot exist in mount point, any kind of
> > read like md5sum give me IO error from ddsnap.
> > 6. So now we have situation that 1st taken snapshot is unavailable,
> > but somehow zumastor don't report this to user, so I don't know that
> > this snapshot is unavailable now.
> > 7. After restart zumastor daemon 1st taken snapshot is still
> > unavailable but now zumastor reports this by removing mountpoint
> > directory of 1st snapshot and marking symlink as unavailable.
> Sorry for the delay in response, but most of the zumastor team is busily
> working on Tux3 right now (www.tux3.org).
> What you are experiencing seems to be the expected behavior with what we
> call "squashing" snapshots. The problem is that zumastor is trying to
> save more data in the snapshot store than there is room for, so
> something has to give. In the default case, the oldest snapshot is
> It is possible to make a snapshot "un-squashable" by setting the
> priority on it to the highest value (127). As you would expect, the
> snapshots of higher priority will be removed last. And those with the
> highest possible value with never be squashed (failing IO to the origin
> rather than allowing squashing).
> Another issue (especially if this is a new filesystem), is that you may
> be snapshotting what is "free space" as far as the filesystem is
> concerned. We had some discussion about adding some hooks to avoid
> doing this copy out to save snapshot space.
> A better solution is sharing free space between the origin and snapshot
> (which is one of the things Tux3 is designed to do), and that technology
> should eventually be ported back to zumastor. This is also a
> performance optimization because the origin is "re-mapped". There is
> the downside that you won't be able to disable zumastor and access the
> origin as you normally would.
> Do you have any thoughts on how we could make zumastor more
> user-friendly in this respect? (squashing snapshots, how to notify user,
> Thanks for the report!
Thanks for Your answer. Could you tell me how to set priority for the
snapshot because I can't find it in documentation.
I think to make Zumastor user-friendly is change notify user when
snapshot is full and remove unavailable snapshots without restart
I'm going to continue testing Zumastor.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at