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
lesmikes...@gmail.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@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
