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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).