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,
---
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 latest
change
(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
On Mon, Mar 5, 2012 at 1:51 PM, Anand Jain anand.j...@oracle.com 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,
On 05.03.2012 08:07, Fajar A. Nugraha wrote:
On Mon, Mar 5, 2012 at 1:51 PM, Anand Jain anand.j...@oracle.com 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
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
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 find-new
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
find-new
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 anand.j...@oracle.com 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
From: Anand Jain anand.j...@oracle.com
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
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
12 matches
Mail list logo
