Jon Craig wrote at about 16:23:44 -0400 on Monday, August 31, 2009:
 > On Mon, Aug 31, 2009 at 3:23 PM, Jeffrey J.
 > Kosowsky<backuppc AT kosowsky DOT org> wrote:
 > 
 > >
 > > I really fail to understand the dogged resistance to finding a viable
 > > solution to a well-known and repeated issue with BackupPC that does
 > > not rely on filesystem level kludges. I could see if this were given
 > > as a temporary workaround but why should we continue to see this as
 > > the ideal solution rather than trying to work on a more robust and
 > > comprehensive solution even if it falls to a long-term roadmap item.
 > >
 > 
 > I don't know who started calling "hard links" a kludge, but I hardly
 > feel the characterization is accurate.  Use of hard links to reduce
 > disk usage dates back to the inception of hard links.  It's not a
 > kludge, its an established feature of unix based filesystems.  Saying
 > BackupPC's use of hard links is a kludge is like saying the use of
 > standard filesystems to store files is a kludge.  Try suggesting to
 > the Unix community that hard links need to be removed because their a
 > kludge and the response would look similar to a DDOS attack on your
 > email account.

It's not the use of hard-links itself that is a kludge as much as the
fact that using hard-links in this manner creates the need for
multiple other kludges and related issues. Including attrib files
standing in for databases and the fact that few if any filesystems and
associated tools were designed to work efficiently with such a large
volume of hard links.

 > 
 > The argument for a SQL based vs. flat file based meta data is
 > definitely a valid discussion and it has no answer until you come up
 > with a list of requirements for your meta data and match it to a
 > technology.  

I wouldn't call the attrib construct to be flat file based meta
data. I would call it a kludgey and limited approximation of a
database or filesystem architecture. This is my whole point, we
already are implicitly using multiple database-like constructs through
the difficult-to-extend, inefficient, and non-standard attrib
construct so why not do it right via a real integrated, relational database.

> I feel use of DB Blobs to store file content would be a
 > tragedy.  If someone wants to argue this, then lets have that
 > argument.
I have yet to hear anybody seriously argue for this.

 >   SQL DB to store config information has potential merit, but
 > I think it could be argued multiple ways depending on what you value
 > as important (ease of configuration via "vi" vs ease of third party
 > tools to read, understand, modify config info).
I'm relatively neutral here. Though moving to a database format could
 potentially also solve some of the recently discussed requests for
more flexible inheritance and grouping of backup sets.

 > SQL DB to store file
 > meta data has potential, but assuming it would be faster / more
 > flexible than other methods is to avoid the exercise of determining
 > what is important.

I can almost guarantee that almost *anything* would be faster than the
current attrib file construction when it comes to manipulating backups.

 > 
 > SQL is one of many storage solutions.  It has strengths and
 > weaknesses.  Lets make sure we understand all the options and match
 > technology strengths to the requirements.
 > 
 > Lastly, we wouldn't be having a discusion about replicating the
 > backuppc server if backuppc wasn't as stable and robust as it is.
 > BackupPC must first and foremost be a reliable and trustworthy
 > repository of backup data.  It having the ability to replicate itself
 > for "DR" purposes comes second.

As I mentioned before, backing up BackupPC is only one of the many
reasons for moving to a database structure for file and backup meta-data.

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