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

Re: [Bacula-devel] FileSet refactoring mockup (was: Re: Bacula Status)


Hello,

I don't want to discourage discussion of this issue because I also find the 
current FileSet setup a bit more complicated than it needs to be, but I do 
have two comments:

1. The developers won't be too interested in this subject because we are at 
the end of a development cycle, and so major redesigns of the FileSet will 
need to be put off until the beginning of a development cycle (i.e. sometime 
early next year).

2. After a quick look at what you propose, I am not convinced that it is 
really simpler, it just moves some directives from one section to another, 
and in doing so, it seems to me (I may be wrong) that it removes a current 
capability that we can have excludes and includes acting on the same 
directory.

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?   If you know how to 
implement the above, please draw me a block diagram flow chart of how to 
program it. Perhaps you are implicitly assuming that the directories in an 
Exclude were previously Included, but in your example, they were not.

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

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

Best regards,

Kern


On Monday 13 October 2008 14:58:17 Marc Schiffbauer wrote:
> * Martin Simmons schrieb am 07.10.08 um 13:23 Uhr:
> > >>>>> On Tue, 7 Oct 2008 07:37:36 +0200, Kern Sibbald said:
> > >
> > > I personally don't find it that confusing, but am willing to admit that
> > > some would.  So, what is the solution?
> > >
> > > Drop the feature?
> > >
> > > Change the feature?
> >
> > Putting it outside the Include option and making it truely apply to the
> > whole fileset would at least make it easier to define what it does.
> >
> > > If it involves programming, please realize that this is contributed
> > > code, and so any changes would have to be agreed on by some sort of
> > > consensus, and then done by someone other than the developers or
> > > perhaps by the author.
> >
> > I think the fileset syntax needs a complete overhaul.
>
> I thought about this some time now. Conclusion: The current
> FileSet{} Syntax is good, but IMO with some changes/improvements
> it would be much more logical and easier to understand.
>
> So I did a bit of a "Mockup" what I think how the FileSet would be
> better structured maintaining the same flexibility:
>
> 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.
>
> # Example fileset with comments:
> -------------------------------------------------------
> FileSet {
>   Name = "MyFileSet"
>
>   Ignore FileSet Changes = <yes|no> # no change
>   Enable VSS = <yes|no>             # no change
>
>   Include {        # include /dev/sdf raw with sparse option
>
>     Options {      # this option matches all File* statements
>       Sparse = YES # within this Include statement
>     }
>
>     File = "/dev/sdf"
>   }
>
>   # include some dirs, SHA1 for every file,
>   # compress all files not matching ".*\.(gz|bz2|tgz|tbz2)"
>   Include {
>     Options {            # this option matches all File* statements
>       Signature   = SHA1 # within this Include statement
>     }
>
>     # compress all files in this include section
>     # _not_ matching ".*\.(gz|bz2|tgz|tbz2)"
>     Options {
>       WildRegex      = !".*\.(gz|bz2|tgz|tbz2)"
>       Compression = GZIP
>     }
>     File      = "/"             # begin at root, stay in FS
>     File      = "/usr"          # additional FS mounted on /usr
>     FileWild  = "/lib*"         # include /lib, /lib32, /lib64, ...
>     FileWild  = "/usr/lib*"     # include /usr/lib, /usr/lib64, ...
>     FileRegex = "/home/[a-f]*"  # include all home dirs beginning
>                                 # with one of a,b,c,d,e,f
>   }
>
>   # exclude some of the previous selected files that we do not want
>   # to backup:
>   # everything in /tmp and every cache dir in user home dirs
>   # this applies to any files that matched previously because this
>   # section is at the end and thus processesd when!
>   Exclude {
>     File = /tmp
>     FileRegex = "/home/*/[Cc]ache"
>   }
> }
> -------------------------------------------------------
>
> Comments please!
>
>
> Regards
> -Marc



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