Les Mikesell wrote at about 17:22:27 -0500 on Monday, August 31, 2009:
 > Jeffrey J. Kosowsky wrote:
 > >
 > >  > > I have seen problems where the attrib files are not synchronized with
 > >  > > the backups or when the pc tree is broken. In fact, that is the reason
 > >  > > I wrote several of my routines to identify and fix such problems. Now
 > >  > > true, the cause is typically due to crashes or disk/filesystem issues
 > >  > > outside of the direct scope of BackupPC but there are real-world
 > >  > > synchronization and integrity issues that can arise.
 > >  > 
 > >  > But nothing you've proposed will make any difference in this respect. 
 > >  > Well, maybe different, but nothing to enforce additional 
 > > synchronization 
 > >  > with the file content.
 > > 
 > > Except that it is easier to back up a database than to back up
 > > thousands if not millions of scattered attrib files.
 > 
 > Is it?  I think rsync or tar would handle them rather easily and toss 
 > them on about any media without regard to having a matching database 
 > application running.  

It would take a lot longer since it would be implicitly doing a "find"
down a very large pc tree.

 > Why is it OK require a sql database application 
 > but not something like zfs?

Yes I know you run Open Solaris. However, 99.99% of computer users
don't so we don't have access to zfs. On the other hand free sql
database applications are available on just about any OS. Why is so
hard to understand that Open Solaris is not just an option for the
average user. It is also a lot easier to install a vanilla sql
database app then to set up and maintain a new Open Solaris server
just to run BackupPC.

This is getting ridiculous. Just because BackupPC meets the needs of
your particular environment doesn't mean that it meets other peoples'
needs.

 > > Also, there are
 > > well-known tools for checking database consistency while you need to
 > > write custom ones for attrib files. 
 > 
 > I've found them to be as reliable as the underlying filesystem.  Perhaps 
 > that is your real problem.

Then that is good I suppose since everyone was arguing for how
reliable filesystem-based tools are.

 > 
 > >  > > Indeed, there is no
 > >  > > question in my mind that a single well-constructed relational database
 > >  > > would be orders of magnitude faster here.
 > >  > 
 > >  > Until you go to get the data, which is kind of the point.
 > > 
 > > I can only tell you how slow and non-optimized the current
 > > implementation is. Do you really believe that a relational database
 > > wouldn't be significantly faster than the current approach
 > > finding/opening/reading/decompressing/parsing multiple layers of
 > > attrib files?
 > 
 > It could be, if it were optimized for that.  
I don't think it would need optimizing to be faster.

 > But updating them might be 
 > slower, finding the records that need to expire and releasing their 
 > space might be a lot slower
Optimization would be important for expiring. Though how much slower
is anyone's guess?

 > and the usual case of getting both the 
 > attributes and the data at the same time would probably be the same or 
 > worse.

Highly unlikely. Why would a single database query and filesystem lookup be
slower than having to find/open/read/decompress/parse an attrib file?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/