xfs
[Top] [All Lists]

Re: exclusion of trees with xfsdump

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: exclusion of trees with xfsdump
From: Rumi Szabolcs <rumi_ml@xxxxxxx>
Date: Mon, 27 Mar 2006 23:15:32 +0200
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <442818FD.5040904@xxxxxxx>
References: <20060327173157.414914f6.rumi_ml@xxxxxxx> <442818FD.5040904@xxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On Mon, 27 Mar 2006 10:55:25 -0600
Bill Kendall <wkendall@xxxxxxx> wrote:

> On 03/27/06 09:31, Rumi Szabolcs wrote:
> > So at least with XFS the possible route seems to have a single
> > large filesystem holding all data and exclude non-important files
> > from dumps. This would be a lot easier to do if xfsdump would
> > support flagging a directory with an SGI_XFSDUMP_SKIP_DIR or
> > similar attribute in order to skip it's contents recursively
> > without having to flag every single file inside. Would this be
> > possible to implement in xfsdump?
> 
> Actually excluding subtrees is already supported, but not
> explained in the xfsdump man page until recently:
> 
> |  To tag all files in a subtree for exclusion from the dump:
> |
> |       $ chattr -R +d directory
> |
> |  Note that any new files or directories created in a directory
> |  which has the  "no dump" attribute set will automatically inherit
> |  this attribute.
> 
> After this is done, make sure to use the -e option on xfsdump so
> that xfsdump will honor the "no dump" inode flag.
> 
> Bill

Well, I really never heard about this method but this is
similar to using

find /nobackup -type f -exec attr -s SGI_XFSDUMP_SKIP_FILE {} \;

or similar but the latter of course has to be done every time before
a dump of the appropriate filesystem is executed.

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
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.

Thanks,

Szabolcs


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