Jeffrey J. Kosowsky wrote:
> 
> For me the biggest limitation is that it doesn't store extended
> attributes and ACLs. I have looked (briefly) into extending that
> functionality and in fact it was that effort that led me to think that
> a database is the way to go.

But that really has nothing to do with the way they are stored. The 
attrib mechanism could be extended or a parallel extended-attrib text 
file could be added when you have a client capable of passing the 
relevant data.

> Otherwise adding additional attributes to
> the attrib file just seems kludgey since there is no good general
> purpose way to store/access them. Plus, the more attributes you store,
> the slower it all will become since you will still in general need to
> read in and unpack the entire attrib file to find just one piece of
> information. Then my thinking was that once you start rewriting it all
> in an abstracted objected-oriented fashion then you might as well go
> the next step and store it in a database rather than having to
> re-create all the database-like functionality.

There's one big missing piece.  If you don't put the file contents in 
the database, how do you know that the name of the file that you have in 
the database actually refers to something that holds the correct 
content?  And if it doesn't, how do you fix it?  In the current scheme 
you have kernel-atomic operations arbitrating the concurrent processes 
that are writing things.  Can you match that reliability some other way? 
  With hardlinks, the pooled hash filename only exists in one place and 
if two processes try to create the same file one will fail and know it. 
  You can delete the whole pool subsequently and all of the links under 
the pc directories will still have the correct content.  With a database 
you have to create the hashed name in both the database and filesystem 
with separate things that can go wrong and a window of time where 
processes can compete, and you then must always trust that the filename 
holds that content for as long as any references exist.

> The second limitation that has been discussed ad-nauseum is that hard
> links make it difficult to move, copy, or split the pool across disks.

Which has an assortment of easy solutions, the easiest of all being to 
just get a big disk.

> The other advantages that I mention then come along mostly for the
> ride once you implement a database backend.

But at the tradeoff of disconnecting the metadata like the actual 
filename from the content that it is supposed to represent.

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