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 /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? > > 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 -- Arvin Schnell, <aschnell@xxxxxxx> Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
