lkml.org 
[lkml]   [2002]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: linux-2.5.4-pre1 - bitkeeper testing
From
Date
Josh MacDonald <jmacd@CS.Berkeley.EDU> writes:

> Quoting Larry McVoy (lm@bitmover.com):
> >
> > I'm sure it does, you are promoting xdelta, so anything else must be bad.
> > I am a bit curious, do you even know what a weave is? Can you explain
> > how one works? Surely, after all that flaming, you do know how they
> > work, right?
>
> Of course. But disk transfer cost is the same whether you're in RCS
> or SCCS, and rename is still a very expensive way to update your files.

Hmm. Up to a certain point something like 256K disk I/O for an entire
file can be done with single seek. So that is constant time. Not in
all cases but in the normal case for source code files it is. And beyond
that you get an extra seek for the inode and the directory. The only
part that rename removes is touching the directory. And given that
there is no requirement that rename be synchronous I don't see rename
waiting for the directory change to complete. I can see problems
currently with large directories, but those problems are orthogonal to
the issue of just rename being slow.

So for source code sized files why is rename expensive?

I guess I can see some merit if you are processing thousands of
operations a second where the sheer volume of data makes things
expensive but I don't see that being the common case.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.082 / U:1.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site