Thanks for the explanation!
On Mon, 2 May 2011 21:12:22 -0700
Michael Barton mike-launch...@weirdlooking.com wrote:
What I've been playing with is having a manifest that contains hashes
of (4mb) chunks for the volume's backups. When a user initiates a new
backup, dm-snapshot does its thing
On Mon, 2 May 2011 21:19:43 -0700
Michael Barton mike-launch...@weirdlooking.com wrote:
Oh, and I don't know if keeping track of dirty chunks so backups are
less work is worth putting an indirection layer on top of volumes.
I think that it depends on volume capacity and the frequency of
Hello Mike, Tomo:
I invite you to take a look at Livebackup for kvm:
http://wiki.qemu.org/Features/Livebackup
This is a feature that I am currently developing. In brief, livebackup
enables full and incremental backups of running VMs.
It has enhancements to qemu that enable it to keep an
On 05/02/2011 01:46 PM, Chuck Thier wrote:
This leads to another interesting question. While our reference
implementation may not directly expose snapshot functionality, I imagine
other storage implementations could want to. I'm interested to hear what use
cases others would be interested in
At Tue, 03 May 2011 12:19:50 -0700,
Josh Durgin wrote:
On 05/02/2011 01:46 PM, Chuck Thier wrote:
This leads to another interesting question. While our reference
implementation may not directly expose snapshot functionality, I imagine
other storage implementations could want to. I'm
On May 2, 2011, at 12:50 PM, FUJITA Tomonori wrote:
Hello,
Chuck told me at the conference that lunr team are still working on
the reference iSCSI target driver design and a possible design might
exploit device mapper snapshot feature.
You're involved in the tgt project and it is the tgt
You're involved in the tgt project and it is the tgt project's purgative to
add features as seen fit, but are you sure that you want to support this
feature?
Major spell check fail: prerogative ;-)
Regards,
Eric Windisch
e...@cloudscaling.com
On Mon, May 2, 2011 at 2:45 PM, Eric Windisch e...@cloudscaling.com wrote:
On May 2, 2011, at 12:50 PM, FUJITA Tomonori wrote:
Hello,
Chuck told me at the conference that lunr team are still working on
the reference iSCSI target driver design and a possible design might
exploit
On Mon, 2 May 2011 15:45:20 -0400
Eric Windisch e...@cloudscaling.com wrote:
You're involved in the tgt project and it is the tgt project's
purgative to add features as seen fit, but are you sure that you
want to support this feature?
I'm the maintainer so I can add anything useful unless I
Surely, FUSE is another possible option, I think. I heard that lunr
team was thinking about the approach too.
I'm concerned about the performance/stability of FUSE, but I'm not sure if
using iSCSI is a significantly better option when the access is likely to be
local. If I had to choose
Is Swift as a Block device a real option? It looks to me that
performance will be a big problem. Also how the three copies of Swift
will be presented as iSCSI? Only one? Each one with its own iSCSI
target? Who serialize the writes in this scenario?
Nelson
On Mon, May 2, 2011 at 6:11 PM, Eric
On Mon, 2 May 2011 21:11:22 -0400
Eric Windisch e...@cloudscaling.com wrote:
I expect there will be great demand for an implementation of a Swift
as a block device client. Care should be made in deciding what will
Surely. I also modified tgt to simply store data on Swift. It doesn't
work well
We have no current plans to make an iSCSI target for swift. Not only would
there be performance issues, but also consistency issues among other things.
For Lunr, swift will only be a target for backups from block devices.
I think some of this confusion stems from the confusion around snapshots,
What I've been playing with is having a manifest that contains hashes
of (4mb) chunks for the volume's backups. When a user initiates a new
backup, dm-snapshot does its thing and gives me a block device. I
read and hash chunks from that block device and compare them to the
manifest, uploading
On Mon, May 2, 2011 at 9:12 PM, Michael Barton
mike-launch...@weirdlooking.com wrote:
What I've been playing with is having a manifest that contains hashes
of (4mb) chunks for the volume's backups. When a user initiates a new
backup, dm-snapshot does its thing and gives me a block device. I
15 matches
Mail list logo
