Michael Stowe wrote at about 16:29:40 -0500 on Monday, August 31, 2009:
> > Michael Stowe wrote at about 15:48:17 -0500 on Monday, August 31, 2009:
> > >
> > > > > In other words, I'd suggest that working around the limitations of
> > your
> > > > > consumer-grade NAS is probably beyond the scope of any backup
> > system.
> > > >
> > > > How nice of you. And please remind me of all the code you have
> > > > contributed to BackupPC and to this user group...
> > >
> > > I don't think a discussion of scope really merited an ad hominem
> > attack.
> > > Personally, I think engaging in personal attacks weakens your
> > arguments.
> >
> > Perhaps next time don't cut out the critical preceding quote where you
> > implied
> > that my usage was "fringe". My answer makes sense a lot more sense in
> > that context and comes across as less ad hominem.
>
> Well, then, I'll quote it:
> "While I'm not sure I'd go so far as to call a consumer NAS a fringe case,
> it's certainly limits your options."
>
> My typo aside, I don't think a reasonable person could glean from that
> that a) I'm calling consumer NAS a fringe case, or b) that a reasonable
> response to this is to attack me or my contributions.
>
> Frankly, I'm not sure why it appears to be such an emotionally charged
> issue, and I can't imagine an optimal technical solution resulting from
> rage or personal attacks. And regardless of how you manage to read or
> misread a member's comments, I shall have to respectfully ask you to keep
> it civil. There's no reason to get personal or unprofessional.
>
Words like "fringe", "shenanigans" are pejorative - no matter how you
couch it. My response was hardly ad-hominem, but rather suggesting if
you went based on actual contributions to the BackupPC community then
you would be way more fringe than me -- that's all.
> > Is it self-evident that a BackupPC tree is difficult to
> > copy/move/resize if not on a dedicated filesystem?
>
> No, but that's quite different from what you were suggesting earlier --
> nor, frankly, is a dedicated filesystem really the issue, but it is a
> large number of directory entries making several styles of file copying
> impractical.
That is exactly what I was suggesting -- to warn and educate users
about these issues.
> > You haven't even begun to listen or to read through the archives. It
> > is not my job to rehash every past long and informative discussion for
> > the benefit of newbies who prefer to argue and nitpick rather than to
> > educate themselves on past discussions.
>
> You may argue about the context, but are you attempting to use the word
> "newbies" in something other than an insulting context?
Newbie as in new to this community -- no insult intended since all of
us start as newbies. You seem to be remarkably thin-skinned (is that
ad-hominem too?) in seeing insults where none were intended.
>
> If the discussion was already had and settled, then why rehash only part
> of it? Why, frankly, rehash any of it?
It's not settled. Opinions differ and the same issues keep arising. In
truth, there is no real well-defined long-term roadmap for BackupPC
and Craig is the ultimate arbiter based on his time and preferences
since almost all of the coding is done by him. Whether this is good or
bad is for another discussion. But the result is that such discussions
don't truly get resolved in any public way but they are hopefully healthy
nonetheless in terms of giving input to Craig and exploring potential
solution paths.
Rehashing the issues while perhaps inefficient does at least serve the
purpose of keeping various unmet needs and alternatives perspectives
alive in the absence of a more formal development structure.
>
> > There has been a lot of discussion of the pros-and-cons. I suggest you
> > educate yourself on that first before shooting.
>
> I can't imagine how this would help anything. I'm quite familiar with
> BackupPC, as well as databases and file systems.
Familiar as a user or as a developer? The issues we are discussing go
way beyond the Unix 101 concept of "hard links" and have to do with
the detailed implementation of things like attrib files and potential
extensions to ACL's and extended attributes. If you are familiar with
the code and know how to do this best, then please share with us.
>
> > To be fair, the
> > discussions have not progressed beyond laying out general pros-and-cons
> > -- i.e., no one has yet to start designing a specific solution. Though
> > I think few would argue that one is possible with the caveat that
> > there are pros-and-cons to different approaches and that different
> > users value them differently. That being said, I believe that there is
> > a lot of value to the discussion so far in that it outlines potential
> > directions for future development whether or not they are ever fully
> > pursued.
> >
> > In all seriousness, I suggest that you delve into the code and in
> > particular the handling of attrib files and you will see that it is
> > not all so neat-and-clean as creating hard links.
>
> I'm quite familiar with it, and I'm just not sure where you're going with
> this. What is the problem with the handling of attrib files that needs to
> be solved?
I have already mentioned this multiple times:
Attrib files are:
1. Slow/inefficient/scattered
2. Kludgey/difficult to extend to ACL's and extended attributes
3. Fragile and disconnected from the file source (non-atomic also)
4. Require kludges like file name mangling
5. Handle hard-links in a non-symmetric manner
6. Contain redundant information
Not all of these need to be solved but many if not all of them would
be solved by a database approach.
#2 is a real show-stopper if you want to back up a Windows system
properly.
------------------------------------------------------------------------------
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/
|
