[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] FileSet refactoring mockup


* Kjetil Torgrim Homme schrieb am 15.10.08 um 13:07 Uhr:
> Kern Sibbald <kern@xxxxxxxxxxx> writes:
> 
> > 3. Your use of the Exclude {} section, in for example:
> >>   Exclude {
> >>     File = /tmp
> >>     FileRegex = "/home/*/[Cc]ache"
> >>   }
> >
> > won't work (it seems to me) unless there are some implicit
> > assumptions that I am not aware of. How can you apply an "exclude"
> > with a regex on the /home directory if that directory has never been
> > included?
> 
> the Exclude rules are only applied on files which match one of the
> Include sections.  the example FileSet had two Include and one
> Exclude.

Correct!

> 
> > 4. The same comment as #3 applies to your statements that are in the
> > Include {} section. To implement them, you need to assume some sort
> > of implicit inclusion of directories that have a wild card in them,
> > and to do that you will have real nightmares scanning wild card
> > statements or regexes to try to see what directories are implicitly
> > included, OR Bacula must implicitly transverse *all* filesystems
> > that are mounted, which is a performance nightmare, and not
> > desirable IMO (unless we implement some new feature, which I have
> > always wanted, that says "include all xxx filesystems" where xxx
> > could be local, mounted, or particular filesystem types).
> 
> you will only have to traverse all filesystems if OneFS is false.
> sure, it may be slightly tricky to implement a clever cutoff.  e.g.,
> with
> 
>   Include { File = "/" }
>   Exclude {
>     FileRegex = "/var/(spool|run)/squid"
>     File = "/home/*/cache"
>   }
> 
> you really don't want to traverse /var/spool/squid to look for files
> matching /home/*/cache ...  hmm, actually that's pretty easy to
> implement -- if it matches: no more traversal for you!

Those are always absolute paths. So if two Exclude statements begin
with a different directory they will always match different trees.

Or did I not get the point here?


> 
> > The bottom line is that the whole needs to fit together with a set
> > of rules that are clear so that it can be programmed, and they may
> > exist for your proposal, but it is not obvious to me, so I would
> > like to see those rules (or flow chart).

Yes, ACK. The rules that I wrote were only a first cut. They will
have to be extended and rendered more precisely.

> 
> >On Monday 13 October 2008 14:58:17 Marc Schiffbauer wrote:
> >> Some definitions (many apply to the current syntax):
> >>
> >>  * There are two possible sections in "FileSet": "Include" and "Exclude"
> >>    There can be one or more Include and zero or one Exclude
> >>    statements.
> >>  * NEW: FileWild and FileRegex, not only File can be used to select
> >>    files in Include and Exclude
> >>  * All files matching one of the File* statements will be included into or
> >>    excluded from the backup accordingly.
> >>  * Any File/FileRegex/FileWild statements can begin with a "!" to
> >>    negate it.
> >>  * What will be backed up or not can never be controlled from within
> >>    an "Options" section.
> >>  * Options sections will always only set/change parameters of
> >>    files being selected for that particular include statement.
> 
> here are two additional rules I think Marc implied:
> 
>     * All Include sections are evaluated before the Exclude section.

Right!

Or with other words: For every directory or file that is scanned
because of an Include statement, all Exclude patterns have to to be
applied to it, and if one matches that directory or file will be
dropped from the list and not backed up.


> 
>     * When an Exclude statement matches a directory, it will not be
>       recursed into.

Right!

> 
> another thing which needs to be stated:
> 
>     * If more than one Include section matches, all their Options are
>       applied.  If the options conflict, the setting which comes last
>       in the configuration file has presedence.  (e.g., "is
>       compression on or off?")

Good point. And I agree that what you describe will be the most
intuitive behavior.


> 
> what users will want is "most specific match wins", but that's really
> hard to determine objectively.

I would imply, that the include statements will be applied in the
order they appear in the config. And that later statements will
overwrite earlier ones if they conflict. I think this is the most
natural behavior and is what most software does in such cases.

I started a new page on the bacula wiki to gather information and
ideas about those definitions, config "mockups" and the like.

Please contribute!

-Marc

-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.