gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Fwd: Snapshot feature design review


From: Paul Cuzner
Subject: Re: [Gluster-devel] Fwd: Snapshot feature design review
Date: Sun, 27 Oct 2013 23:26:44 -0400 (EDT)

Hi,

I've just reviewed the doc, and would like to clarify a couple of things 
regarding the proposed design.


- I don't see a snapshot schedule type command to generate automated snapshots. 
What's the plan here? In a distributed environment the schedule for snapshots 
should be an attribute of the volume shouldn't it? If we designate a node in 
the cluster as 'master' and use cron to manage the snaps - what happens when 
this node is down/rebuilt or loses its config? To me there seems to be a 
requirement for a gluster scheduler - to manage snapshots, and potentially 
future tasks like post dedupe, data integrity checking or maybe even geo-rep 
intervals etc.

- snapshots are reliant upon dm-thinp, which means this version of lvm is a 
dependancy. Is there a clear path of migrating from classic lvm to dm-thinp 
based lv's - or is snapshots in 3.5 basically going to be a feature from this 
point forward i.e. no backwards compatibility.

- when managing volumes holding snaps, visibility of capacity usage attributed 
to snaps is key - but I don't see a means of discerning the space usage by snap 
in the CLI breakdown.

- on other systems, I've had hung backup tasks (for days!) holding on to snaps 
causing space usage to climb against the primary volume. In this scenario I was 
able to see snap usage and what client had the snapshot open to troubleshoot. 
In this scenario, how will the glusterfs snapshot present itself and be managed.

- How will the snapshot volume be perceived by Windows clients over SMB? Will 
these users be able to use the previous versions tab for example against the 
file properties in explorer?

- a volume snapshot is based on snaps of the component bricks. 3.4 changed the 
way that bricks are used on a vol create to require a dir on a filesystem not 
the filesystem itself. This change enables users to create multiple volumes 
from the same physical brick by placing different dirs on the bricks root - 
which is not necessarily a good idea. Given the 1:1 requirement of 
brick:volume, will this CLI behaviour be regressed to the way it was with 3.3.

Happy to talk further about any of the above, if needed.

Regards,

Paul Cuzner






----- Original Message -----
> From: "Nagaprasad Sathyanarayana" <address@hidden>
> To: address@hidden
> Sent: Friday, 18 October, 2013 5:22:31 AM
> Subject: [Gluster-devel] Fwd: Snapshot feature design review
> 
> Gluster devel included.
> 
> Thanks
> Naga
> 
> Begin forwarded message:
> 
> 
> 
> 
> From: Nagaprasad Sathyanarayana < address@hidden >
> Date: 17 October 2013 9:45:05 pm IST
> To: Shishir Gowda < address@hidden >
> Cc: " address@hidden " < address@hidden >, " address@hidden " <
> address@hidden >, " address@hidden " < address@hidden >, "
> address@hidden " < address@hidden >, " address@hidden " <
> address@hidden >, " address@hidden " < address@hidden >, "
> address@hidden " < address@hidden >, " address@hidden " <
> address@hidden >, " address@hidden " < address@hidden >, "
> address@hidden " < address@hidden >, " address@hidden " <
> address@hidden >
> Subject: Re: Snapshot feature design review
> 
> 
> 
> 
> + Gluster devel.
> 
> Hi all,
> 
> Kindly review the design and provide any comments by next week. We are
> targeting to have the review comments incorporated in the design and post
> the final design by 28th of this month (October). If you need any discussion
> on the design, please let us know by 21st or 22nd this month.
> If anybody not copied must be involved in design review, please feel free to
> forward the design document to them.
> 
> Thanks
> Naga
> 
> 
> 
> On 16-Oct-2013, at 7:03 pm, Shishir Gowda < address@hidden > wrote:
> 
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> 
> 
> The design document has been updated, and we have tried to address all the
> review comments and design issues to the best of our ability.
> 
> 
> 
> 
> 
> Please review the design and the document when possible.
> 
> 
> 
> 
> 
> The design document can be found @
> https://forge.gluster.org/snapshot/pages/Home
> 
> 
> 
> 
> 
> Please feel free to critique/comment.
> 
> 
> 
> 
> 
> With regards,
> 
> 
> Shishir
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]