From: Arvin Schnell <aschnell@suse.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] [RFC] Add btrfs autosnap feature
Date: Fri, 2 Mar 2012 12:34:21 +0100 [thread overview]
Message-ID: <20120302113421.GA6214@suse.de> (raw)
In-Reply-To: <CAE5mzvjiL+81AsSspTrE1A1BBiL27zJ1qK1oqCF27oL+-CG9Mw@mail.gmail.com>
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 a=
t
> 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 /var/run is for). It's also a lot of io to
> stat every file in the subvolume every time you make a snapshot, and
> I'm not convinced that the walk is actually correctly implemented:
> what stops an autosnap of / from including all of /proc and /sys in
> the hash?
>=20
> 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 does not report anything, see the reply to my
mail here one year ago [1]. Also for newly created empty files
find-new reports nothing, the same with metadata changes.
If I'm wrong or find-new gets extended I happy to implement it in
snapper.
Regards,
Arvin
[1] http://www.spinics.net/lists/linux-btrfs/msg08683.html
--=20
Arvin Schnell, <aschnell@suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6=
rffer, HRB 16746 (AG N=FCrnberg)
Maxfeldstra=DFe 5
90409 N=FCrnberg
Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-03-02 11:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 2:59 [RFC] [PATCH] Add btrfs autosnap feature asj
2012-02-29 2:59 ` [PATCH] [RFC] " asj
2012-02-29 3:38 ` Anand Jain
2012-03-01 11:54 ` cwillu
2012-03-02 11:34 ` Arvin Schnell [this message]
2012-03-02 12:04 ` cwillu
2012-03-02 12:25 ` Sander
2012-03-05 6:51 ` Anand Jain
2012-03-05 7:07 ` Fajar A. Nugraha
2012-03-05 7:18 ` Arne Jansen
2012-03-05 10:21 ` Anand Jain
2012-03-05 10:28 ` cwillu
2012-03-01 13:23 ` Roman Mamedov
2012-03-06 7:56 ` [PATCH 1/2] Make find_updated_files to return value instead of printing Anand jain
2012-03-06 7:56 ` [PATCH 2/2] Use transaction id to determin if there is any change in the subvol Anand jain
2012-03-06 9:07 ` [PATCH 2/2 v2] " Anand jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120302113421.GA6214@suse.de \
--to=aschnell@suse.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.