Messages in this thread | | | Date | Mon, 20 Mar 2006 23:32:48 +0000 | From | Al Viro <> | Subject | Re: Question regarding to store file system metadata in database |
| |
On Mon, Mar 20, 2006 at 05:53:08PM -0500, Xin Zhao wrote: > Apparently this comparison is not 100% fair. In my experiment, I > randomly pick pathname from 1.2 million path names to resolve the > inode number. But in your "cp -rl linux2.6 foo1" experiment, you > essentially did directory entry lookup sequentially, which maximize > the possible performance. If you do the same thing in a random > fashion, you will probably get much worse performance. As I said > before, I totally agree that 2000/sec is slow. But the point here is > whether 2000/sec is enough for most scenarios?
It is not; e.g. unpacking a tarball or running make(1) on even a medium-sized tree is going to hurt that way. Moreover, the same goes for a lot of scripts, etc.
And that's aside of the question of CPU load you are inflicting - it's not just 2000/sec, it's 2000/sec _and_ _nothing_ _else_ _gets_ _done_.
BTW, for real lookup speed, try find(1). From hot cache.
> I am not saying existing FS implementation is not efficient. I agreed > that file system has been fully optimized. What I want to say is to > support complex mapping in the system I described before, we might > need some extension on existing file systems. Question is what is the > best extension. Consider how to allow user a, b to share physical copy > f.1, while allowing user c to use private copy f.2? The virtual > pathname to physical pathname should be transparent to end users. That > is, all the users should be able to access right file copies using > virtual path "f". The file system should be able to tell the different > identity and return the data from the right physical copy. That's what > we want to do. But it is hard to achieve without some extension. :)
So what happens upon rename()? - 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/
| |