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

Re: [Bacula-devel] FileSet refactoring mockup

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

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

  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!

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

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

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

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?")

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

regards,          | Redpill  _
Kjetil T. Homme   | Linpro  (_)

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
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.