xfs
[Top] [All Lists]

Re: exclusion of trees with xfsdump

To: Rumi Szabolcs <rumi_ml@xxxxxxx>
Subject: Re: exclusion of trees with xfsdump
From: Bill Kendall <wkendall@xxxxxxx>
Date: Fri, 31 Mar 2006 09:22:35 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20060327231532.5a8292e9.rumi_ml@xxxxxxx>
References: <20060327173157.414914f6.rumi_ml@xxxxxxx> <442818FD.5040904@xxxxxxx> <20060327231532.5a8292e9.rumi_ml@xxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051011)
Rumi Szabolcs wrote:
The chattr method above could really be almost as usable as a real
directory-tree-level flag if the attribute would be inherited in
any real world scenario but it seems it doesn't:

1.) touching a file - it inherits +d
2.) copying a file - it inherits +d
3.) moving a file - it does not inherit +d

Apparently moving a file within the same filesystem from outside
the +d flagged area to inside the area does not inherit the +d
flag (because no new inode is created?). I don't know whether this

Right, the flag is only inherited on inode creation. I'm not aware
of all the reasoning behind this, but it could be to avoid ambiguous
situations where one link to an inode is in a "no dump" directory,
and another link is created in a directory without that flag. Also,
namespace operations don't typically update non-dir inodes, with
the exception of changing the number of links.

should be considered a bug or a feature but there is a good chance
that users are going to move files from their backed up home
directories into the scrap area and then they apparently won't
be automagically flagged as no-backup.

This is easily remedied by running chattr on the directory before
the dump. What you need to watch out for though, is that files created
in the scrap area and later moved will still be set to "no dump."

At this point there is no plan to add support for excluding directories
by name.

Regards,
Bill


<Prev in Thread] Current Thread [Next in Thread>