1 |
Neil Bothwick <neil <at> digimed.co.uk> writes: |
2 |
|
3 |
|
4 |
> > I use snapper from portage. Snapper itself works just fine. |
5 |
|
6 |
Good to know |
7 |
|
8 |
> > found that trying to integrate it into portage (before/after snapshots |
9 |
> > on every emerge) is just way too much overhead (it goes fast, but you |
10 |
> > end up with a bazillion snapshots). Also, I've had deadlock problems |
11 |
> > with deleting multiple snapshots at once, which is certainly a kernel |
12 |
> > problem. |
13 |
|
14 |
Also very good to know. |
15 |
Ftrace/trace-cmd/kernelshark surely would be great to use for this. |
16 |
|
17 |
http://zougloub.eu/overlay/sys-kernel/trace-cmd/ |
18 |
|
19 |
I have not tested this yet.............. |
20 |
|
21 |
|
22 |
> > So, right now I'm using snapper to manage snapshots but I do |
23 |
> > not use time/event-based snapshots at all - I just create them when |
24 |
> > needed and clean them up manually, and carefully. |
25 |
|
26 |
Well my setup is going to be (2) 2T sata-3 drives in a mirrored |
27 |
configuration. So yea, manual will porbably be just fine for me too. |
28 |
|
29 |
|
30 |
> I use a home-brewed script to make time based snapshots, called from |
31 |
> cron - a little like zfs-auto-snapshot. I set a limit on the number of |
32 |
> each type of snapshot so the script generally creates one snapshot and |
33 |
> deletes one snapshot for each subvolume whenever it is called, avoiding |
34 |
> the need to ever have a gazillion snapshots to delete. |
35 |
|
36 |
|
37 |
Sounds good. I grabbed a copy. I drop you a line, if I run into |
38 |
troubles using buttersnap. |
39 |
|
40 |
|
41 |
cheers, |
42 |
James |