Message-ID: <675612.55480.qm@web52503.mail.re2.yahoo.com>
Date:	Sat, 18 Aug 2007 09:45:54 -0700 (PDT)
From:	Marc Perkel <mperkel@...oo.com>
To:	Kyle Moffett <mrmacman_g4@....com>, Phillip Susi <psusi@....rr.com>
Cc:	Valdis.Kletnieks@...edu, Michael Tharp <gxti@...tiallystapled.com>,
	alan <alan@...eserver.org>, Marc Perkel <mperkel@...oo.com>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Thinking outside the box on file systems


--- Kyle Moffett <mrmacman_g4@....com> wrote:

> On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
> > Valdis.Kletnieks@...edu wrote:
> >> It will become even *more* of a "not that common"
> if the lock will  
> >> block moves and ACL changes *across the
> filesystem* for  
> >> potentially *minutes* at a time.
> >
> > It will not take anywhere NEAR minutes at a time
> to update the in  
> > memory dentries, more like 50ms.
> 
> One last comment:
> 
> 50ms to update in-memory dentries would be FRIGGING
> TERRIBLE!!!   
> Using Perl, an interpreted language, the following
> script takes 3.39s  
> to run on one of my lower-end systems:
> 
> for (0 .. 10000) {
> 	mkdir "a-$_";
> 	mkdir "b-$_";
> 	rename "a-$_", "b-$_";
> }
> 
> It's not even deleting things afterwards so it's
> populating a  
> directory with ten thousand entries.  We can easily
> calculate  
> 10,000/3.39 = 2,949 entries per second, or 0.339
> milliseconds per entry.
> 
> When I change it to rmdir things instead, the
> runtime goes down to  
> 2.89s == 3460 entries/sec == 0.289 milliseconds per
> entry.
> 
> If such a scheme even increases the overhead of a
> directory rename by  
> a hundredth of a millisecond on that box it would
> easily be a 2-3%  
> performance hit.  Given that people tend to kill for
> 1% performance  
> boosts, that's not likely to be a good idea.
> 
> Cheers,
> Kyle Moffett
> 
> 

What I suggested was a concept of a new way to look at
a file system. What you are arguing here is why it
wouldn't work based on your theories as to how such a
file system would be implemented. In attacking how
slow you think it might be you are making assumptions
that wouldn't apply to how this would be implemented.
You are assuming that it would be implemented in ways
that you are familiar with. That is a wrong
assumption.

Linux isn't going to make progress when people try to
figure out how to make something NOT work rather than
to make something work. So if you are going to put
effort into this then why not try to figure out how to
get around the issues you are raising rather than to
attack the idea as unsolvable.

When I originally suggested that the names would be a
"hash" I didn't mean that it is going to be only a
hash. You have successfully argued that just a hash
would have problems. Which means that a real solution
is going to be more complex.

I suggest that it would be easier to figure out how to
make moves of large directory structure fast and
effecient with automatic inheritance of rights.

I know it can be done because Microsoft is doing it
and Novell Netware was doing it 20 years ago. So the
fact that it is done by others disproves your
arguments that it can't be done.



Marc Perkel
Junk Email Filter dot com
http://www.junkemailfilter.com


       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists