Re: Zumastor snapshot problem
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. > > Hi, > > 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 > removed. > > 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, > etc). > > Thanks for the report! > Shapor Hi, 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 daemon. I'm going to continue testing Zumastor. Best regards gato --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Zumastor" group. To post to this group, send email to zumastor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/zumastor?hl=en -~--~~~~--~~--~--~---
Re: Zumastor snapshot problem
> On Wed, Nov 19, 2008 at 02:10:05AM -0800, gato wrote: > > > 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. > > > > Hi, > > > > 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 > > > removed. > > > > 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, > > > etc). > > > > Thanks for the report! > > > Shapor > > > Hi, > > 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 > > daemon. > > I'm going to continue testing Zumastor. > > Best regards > > gato > > The priority feature is documented in the ddsnap man page "man ddsnap". > It is not exposed via the zumastor script. I think it would make sense > to add a "prefer snapshots" kind of option to "define master" so you can > inform zumastor to set snapshots of a particular rotatation to > "unsquashable". > > The ddsnap syntax would be something like: > ddsnap priority /var/run/zumastor/servers/ > > Do you have any thoughts on how we could make it more useful, perhaps: > zumastor define volume --nosquash > or for a particular rotation: > zumastor define master ... --daily 7 --nosquash > > Regards, > Shapor Hi, I have been testing ddsnap
Re: Zumastor snapshot problem
> On Wed, Nov 19, 2008 at 02:10:05AM -0800, gato wrote: > > > 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. > > > > Hi, > > > > 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 > > > removed. > > > > 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, > > > etc). > > > > Thanks for the report! > > > Shapor > > > Hi, > > 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 > > daemon. > > I'm going to continue testing Zumastor. > > Best regards > > gato > > The priority feature is documented in the ddsnap man page "man ddsnap". > It is not exposed via the zumastor script. I think it would make sense > to add a "prefer snapshots" kind of option to "define master" so you can > inform zumastor to set snapshots of a particular rotatation to > "unsquashable". > > The ddsnap syntax would be something like: > ddsnap priority /var/run/zumastor/servers/ > > Do you have any thoughts on how we could make it more useful, perhaps: > zumastor define volume --nosquash > or for a particular rotation: > zumastor define master ... --daily 7 --nosquash > > Regards, > Shapor Hi, I have been testing
