From: Anand Jain
This patch adds btrfs autosnap feature. This creates and
saves the autosnap config at /etc/autosnap/config.
Depending on the configuration, autosnap either schedules
the snapshots by updating the crontab or provides an API
to trigger the snapshots from the respective applications
Hi,
This patch added autosnap feature for the btrfs-progs.
The link below provides autosnap guide..
http://btrfs.ipv5.de/index.php?title=Autosnap:_Configure_your_btrfs_to_create_and_manage_snapshots_automatically_based_on_events_or_at_a_regular_frequency
Further there is timeslider, a
There's a few things that bother me about this, not least of all the
assumptions it makes about cron,(notably the direct modification of
crontab files, which is considered to be an internal detail if I
understand correctly, and I'm fairly certain is broken as written),
and how it writes to its own
On Wed, 29 Feb 2012 10:59:36 +0800
asj wrote:
> This patch adds btrfs autosnap feature. This creates and
> saves the autosnap config at /etc/autosnap/config.
> Depending on the configuration, autosnap either schedules
> the snapshots by updating the crontab or provides an API
> to trigger the sna
On Thu, Mar 01, 2012 at 05:54:40AM -0600, cwillu wrote:
> There doesn't appear to be any reason for the scratch file to exist at
> all (one can build up the hash while reading the directories), and
> keeping a scratch file in /etc/ is poor practice in the first place
> (that's what /tmp and/or /va
>> Perhaps all that is unnecessary: rather than doing the walk, why not
>> make use of btrfs subvolume find-new (or rather, the syscalls it
>> uses)?
>
> While developing snapper I faced similar problems and looked at
> find-new but unfortunately it is not sufficient. E.g. when a file
> is deleted
cwillu wrote (ao):
> > While developing snapper I faced similar problems and looked at
> > find-new but unfortunately it is not sufficient. E.g. when a file
> > is deleted find-new does not report anything, see the reply to my
> > mail here one year ago [1]. Also for newly created empty files
> > f
(notably the direct modification of
crontab files, which is considered to be an internal detail if I
understand correctly, and I'm fairly certain is broken as written),
I did came across that point of view however, using crontab cli in the
program wasn't convincing either, (library call woul
On Mon, Mar 5, 2012 at 1:51 PM, Anand Jain wrote:
>
>> (notably the direct modification of
>> crontab files, which is considered to be an internal detail if I
>> understand correctly, and I'm fairly certain is broken as written),
>
>
> I did came across that point of view however, using crontab c
On 05.03.2012 08:07, Fajar A. Nugraha wrote:
> On Mon, Mar 5, 2012 at 1:51 PM, Anand Jain wrote:
>>
>>> (notably the direct modification of
>>> crontab files, which is considered to be an internal detail if I
>>> understand correctly, and I'm fairly certain is broken as written),
>>
>>
>> I did c
Prior to making a new snapshot, grab the (stored) transid of the
previous snapshot, and check if any files have been modified in the
source since that transid: btrfs sub find "${source}"
"${previous_transid}". If nothing is returned, then you don't have to
bother making the snapshot at all, oth
> ---
> sync; read current tran-id and compare
> (new tgw occurs)
> snapshot
> new tgw occurs
> sync; read current tran-id again and store
> ---
>
> which will result in failing to take snapshot even if there are changes.
"btrfs sub find-new /snapshot- -1" shows the transid of the lat
12 matches
Mail list logo
