Les Mikesell wrote at about 12:32:14 -0500 on Tuesday, June 2, 2009:
> Jeffrey J. Kosowsky wrote:
> >
> > > Collisions aren't quite the point - you have to manage that anyway.
> > The
> > > hard part is knowing that the final target you link to is the one that
> > > you wanted, not a something created simultaneously by a different
> > > process doing the same computations, and knowing that the count of
> > > existing links always matches the actual copies. The kernel manages
> > > this automatically when using links. If you have to add an extra
> > system
> > > call to lock/unlock around some other operation you'll triple the
> > overhead.
> >
> > I'm not sure how you definitively get to the number "triple". Maybe
> > more maybe less.
>
> Ummm, link(), vs. lock(),link(),unlock() equivalents, looks like 3x the
> operations to me - and at least the lock/unlock parts have to involve
> system calls even if you convert the link operation to something else.
3x operations != 3x worse performance
Given that disk seeks times and input bandwidth are typical
bottlenecks, I'm not particularly worried about the added
computational bandwidth of lock/unlock.
> > Les - I'm really not sure why you seem so intent on picking apart a
> > database approach.
>
> I'm not. I'm encouraging you to show that something more than black
> magic is involved. Databases sort-of work for some things. They aren't
> particularly better at storing files than a filesystem. If they were,
> we wouldn't use filesystems for anything. You've made a bunch of claims
> about how a database might be better, but so far have not provided any
> evidence to back it up.
I never claimed performance. My claims have been around flexibility,
extendability, and transportability. The use of the database is *not*
to store files -- indeed the files would still be stored as
name-hashed files. The database would be used to store all the
meta-information that now is either stored in the filesystem or stored
in the attrib files (which are a big kludge and certainly not nearly
as well optimized as a modern database can be) or not stored at all
(such as extended attributes and acls). Indeed, if anything filesystem
design is moving towards being more like a database precisely for the
similar need of storing more file-related metadata. If you can find a
filesystem that stores all the above information and gets rid of the
need for the attrib files then I would at least partially accept your
arguments.
I think all (or nearly all) of my 7 claimed advantages are
self-evident. Most are feature-function related and the ones that are
performance related (such as reconstructing a restore view) are
deficits of the current implementation that even you admit.
Again, since the bottleneck is almost always disk I/O or network
bandwidth, I don't think proving database performance is critical plus
I can't prove that to you until the implementation is laid out and
perhaps even implemented. Remember BackupPC can run on 500MHz ARM
machines so I'm not worried about additional processing overhead.
Even if it were a little slower, I would be more than willing to
sacrifice a little inefficiency for a more elegant, extendable,
flexible, and transportable implementation over the current
implementation that kludges together filesystem-specific behaviors
with the kludge of thousands of attrib files. Don't get me wrong, I
think BackupPC is a great program, I just think that it's original
design is showing its limitations as people push to use it to backup
larger systems, other OS's (e.g., Windows) and more advanced
filesystem implementations (e.g., ACLs, selinux.)
> > I can understand someone arguing that it would take
> > too much effort to implement but I don't see the point of challenging
> > the workability of a database approach, particularly when most high
> > end enterprise backup systems do just exactly that (and for good
> > reason!).
>
> One of the 'good reasons' is that most of those systems were designed
> for an OS that didn't have a decent filesystem at the time...
>
There still is no common 'good' filesystem. And we are not all about
to switch to OpenSolaris. Plus, I don't want my backup system to be
filesystem dependent because I might have other reasons for picking
other filesystems or my OS of the future (or of today) might not even
support the filesystem features required. I think good system design
calls for abstracting the backup software from the underlying
filesystem.
> --
> 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/
>
------------------------------------------------------------------------------
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/
|
