Hello Matthew,
As I said, "ignore_fileclass" and "ignore" statements have precedence over
other policy rules,
so if your policy is as you described, entries matching those statements must
have been preserved.
Note there is even no need to reset classes , as entries are matched against
the fileclass definition itself during the policy run (it is not only checking
the entry matches the fileclass name - the one stored in DB, but there is also
a double check the entry attributes do match the fileclass definition
expression. Namely, in you example, "ignore_fileclass = scratch_foo;" results
in matching that entry path effectively matches
tree == "/lustre/scratch/foo").
If I correctly understood, your configuration looks like this:
fileclass scratch {
definition { tree == "/lustre/scratch" }
}
fileclass scratch_foo {
definition { tree == "/lustre/scratch/foo" }
}
cleanup_rules {
ignore_fileclass = scratch_foo;
rule clean_files {
target_fileclass = scratch;
condition { last_access > 14d }
}
}
Or is there anything different?
Do you use the cleanup policy provided in robinhood templates, or did you
define a custom one?
If you used the template, did you made specific changes to the cleanup policy
(e.g. using a recursive action like 'rm -rf') ?
If it's OK to send me your configuration file, I can check it.
Here are a few things you can check/investigate:
- any typo in the specified paths? (an example I have in mind is someone who
had copy-pasted a non printable character in the "tree" expression, so the
specified path looked correct in the configuration, but it was actually not).
- case sensitivity: is the specified path matches the case of the entries you
wanted to preserve?
- If you run "rbh-report -e <entry>" on an entry you want to preserve, you can
see the matched fileclasses. Are they what you expect?
- hardlinks: does the removed entries have several paths in the filesystem
(i.e. are there hardlinks of these entries somewhere else in the filesystem)
Regards,
Thomas
> -----Message d'origine-----
> De : Matthew BETTINGER [mailto:matthew.bettin...@external.total.com]
> Envoyé : mardi 21 janvier 2020 17:07
> À : LEIBOVICI Thomas 601315; robinhood-support@lists.sourceforge.net
> Objet : Re: Nested fileclass behavior
>
> Well that didn't work and resulted in some data loss. I check and the file
> class
> shows no entries. I did run an rbh-config reset classes and rescanned the
> db. I
> dropped the whole db and and remaking it at the moment.
>
> On 1/15/20, 1:48 AM, "thomas.leibov...@cea.fr"
> <thomas.leibov...@cea.fr> wrote:
>
> Hello,
>
> Yes it's safe. Ignore_fileclass rules have the priority over other policy
> rules.
>
> Regards,
> Thomas
>
> > -----Message d'origine-----
> > De : Matthew BETTINGER [mailto:matthew.bettin...@external.total.com]
> > Envoyé : mardi 14 janvier 2020 23:07
> > À : robinhood-support@lists.sourceforge.net
> > Objet : [robinhood-support] Nested fileclass behavior
> >
> > Hello,
> >
> > (running latest robinhood release on centos)
> >
> > I'm trying to prevent deletion of a subdirectory on system that falls
> under a
> > cleanfiles area. What is the proper way to do this to ensure this
> will not
> be
> > deleted ?
> >
> > Here is what we are doing.
> >
> > I have a file class like this
> >
> > fileclass scratch {
> > definition { tree == "/lustre/scratch" }
> > }
> >
> >
> > Then we run clean_files on this area like
> >
> > rule clean_files {
> > target_fileclass = scratch;
> > condition { last_access > 14d }
> > }
> > }
> >
> >
> >
> > If I make a fileclass like
> >
> > fileclass scratch_foo {
> > definition { tree == "/lustre/scratch/foo" }
> >
> > }
> >
> > And add that to ignore_fileclass = scratch_foo
> >
> > Will that get preserved even though it exists under /lustre/scratch
> which
> runs
> > clean_files?
> >
> > Thanks, worst case is I can just make a protected area outside of
> > /lustre/scratch as this is going to be a monthslong run job and last
> thing
> we
> > need is for stuff, this stuff to be deleted =]
> >
> > Matt
> >
> >
> >
> > _______________________________________________
> > robinhood-support mailing list
> > robinhood-support@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/robinhood-support
>
_______________________________________________
robinhood-support mailing list
robinhood-support@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/robinhood-support
