Peter Walter wrote:
> 
>> The first thing needed would be to demonstrate that there would be an 
>> advantage to a database approach - like some benchmarks showing an 
>> improvement in throughput in the TB size range and measurements of the 
>> bandwidth needed for remote replication.
>>
>> Personally I think the way to make things better would be to have a 
>> filesystem that does block-level de-duplication internally. Then most of 
>> what backuppc does won't even be necessary.   There were some 
>> indications that this would be added to ZFS at some point, but I don't 
>> know how the Oracle acquisition will affect those plans.
>>   
> 
> I am a newbie at this, and you obviously are very experienced with Linux 
> and backuppc. However, it seems to me that the features that Jeffrey 
> Kosowsky mentioned would be a very acceptable tradeoff against a 
> reduction in performance, at least for me. I don't think there is a 
> *need* to demonstrate an advantage if you stipulate that you would be 
> comfortable with some reduction in performance. Finally, as someone who 
> has done some database programming with *very* large databases, I don't 
> think there is much to worry about regarding the transaction performance 
> of common databases, such as MySQL.

Would you put the file content in the database or just the equivalent of 
the  directory entries and attributes?  The latter would probably work, 
but then you need something else to manage concurrency between the file 
activity and the database items and tools to fix things if the system 
crashes or ever gets out of sync.  If you would be comfortable with the 
file contents in mysql then you've been working with a different version 
than the ones I've tried.

> Using ZFS or another specific 
> filesystem simply to preserve the requirement to support hard links 
> seems to me to be requiring a specific technology for the technology's 
> sake, instead of  determining which of several available technologies 
> would solve the problem at hand.

Any filesystems with unix/posix semantics will handle hardlinks.  This 
is an instance of using the technology at hand as the obvious solution 
to a problem.

> Why shouldn't backuppc be able to run 
> on an NTFS volume, for instance?

I don't think this is a technical problem.  NTFS claims posix compliance 
and claims to support hard links.  I'm not sure if perl knows how to 
make them or get the link count, though - or if anyone cares.  It seems 
like something that could be fixed if it doesn't already work.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
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/