From: Latchesar Ionkov <lucho@gmx.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Cc: Latchesar Ionkov <lucho@gmx.net>
Subject: Re: [9fans] fuse bashing
Date: Tue, 24 Jan 2006 20:40:26 -0500 [thread overview]
Message-ID: <20060125014026.GA9487@ionkov.net> (raw)
In-Reply-To: <20060125013144.B3BE778FBB@dexter-peak.quanstro.net>
I didn't try tapefs, but ramfs in p9p is slower than u9fs (even after the
fid lookup is improved).
Thanks,
Lucho
On Tue, Jan 24, 2006 at 07:31:44PM -0600, erik quanstrom said:
>
> On Tue Jan 24 18:24:33 CST 2006, lucho@gmx.net wrote:
> > On Tue, Jan 24, 2006 at 02:10:41PM -0600, quanstro@quanstro.net said:
> > > On Mon Jan 23 20:21:36 CST 2006, lucho@gmx.net wrote:
> > > > On Mon, Jan 23, 2006 at 12:06:09PM -0500, Russ Cox said:
> > > > > It appears to match the kernel better, so the implementation
> > > > > should be simpler. (As soon as you want to talk between
> > > >
> > > > It is much simpler (and probably faster), and that's a big win for FUSE:
> > > >
> > > > $ cat fs/fuse/*.[ch] | wc -l
> > > > 4073
> > > >
> > > > $ cat 9p/*.[ch] | wc -l
> > > > 7271
> > >
> > > why do you assume that line count is porportinal to
> > > speed of execution or complexity?
> >
> > Because it doesn't need to convert an alien protocol to Linux VFS. It
> > doesn't need to care about converting error strings to error codes,
> > architecture independent format for the values etc.
>
> even so, these sound like simple translations. they may produce more
> code, but i'm not sure they add complexity.
>
> > It doesn't need to care
> > about unix and tcp sockets. In fact I tested the speed of fuse+fusexmpl
> > compared with v9fs+u9fs, and fuse is noticeably faster.
>
> why didn't you say so? ;-)
>
> i don't use u9fs; was there any indication that v9fs in the kernel was slow?
> have you tried any p9p fileservers? tapefs seemed speedy enough:
>
> ; 9p ls tapefs
> --rw-r--r-- M 0 1000 100 6749246 Feb 5 1998 cyberbit.zip
> ; time 9p read tapefs/cyberbit.zip > /dev/null
> 0.18user 0.20system 0:01.07elapsed 36%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+404minor)pagefaults 0swaps
>
> ; time cat 9/tapefs/cyberbit.zip > /dev/null
> 0.00user 0.01system 0:01.15elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+146minor)pagefaults 0swaps
>
> >
> > If FUSE doesn't handle the interrupts well, that in part explains why is it
> > smaller. The proper signal handling is one of the most complex parts in v9fs.
> >
> > Thanks,
> > Lucho
next prev parent reply other threads:[~2006-01-25 1:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-24 20:10 quanstro
2006-01-24 21:37 ` Eric Van Hensbergen
2006-01-24 23:14 ` Charles Forsyth
2006-01-25 0:26 ` Latchesar Ionkov
2006-01-25 0:25 ` Latchesar Ionkov
2006-01-25 1:31 ` erik quanstrom
2006-01-25 1:40 ` Latchesar Ionkov [this message]
2006-01-25 1:42 ` Eric Van Hensbergen
[not found] <000001c620ca$f86f1570$14aaa8c0@utelsystems.local>
2006-01-24 9:46 ` "Nils O. Selåsdal"
-- strict thread matches above, loose matches on Subject: below --
2006-01-23 17:06 Russ Cox
2006-01-23 17:28 ` Ronald G Minnich
2006-01-23 17:44 ` David Leimbach
2006-01-23 18:07 ` Eric Van Hensbergen
2006-01-23 18:13 ` Bruce Ellis
2006-01-23 20:31 ` David Leimbach
2006-01-23 20:33 ` Ronald G Minnich
2006-01-23 23:28 ` Dan Cross
2006-01-23 23:53 ` David Leimbach
2006-01-24 0:07 ` Ronald G Minnich
2006-01-25 19:58 ` Enache Adrian
2006-01-25 20:30 ` Christoph Lohmann
2006-01-25 20:51 ` Ronald G Minnich
2006-01-25 21:09 ` Bruce Ellis
2006-01-25 20:50 ` Ronald G Minnich
2006-01-25 21:09 ` Enache Adrian
2006-01-24 0:12 ` John Barham
2006-01-25 5:29 ` Dave Eckhardt
2006-01-25 15:38 ` Ronald G Minnich
2006-01-25 21:31 ` Dave Eckhardt
2006-01-26 1:16 ` erik quanstrom
2006-01-25 5:30 ` Dave Eckhardt
2006-01-25 7:46 ` Jack Johnson
2006-01-25 8:11 ` Lyndon Nerenberg
2006-01-25 8:18 ` Lyndon Nerenberg
2006-01-25 9:46 ` Andriy G. Tereshchenko
2006-01-25 15:45 ` Ronald G Minnich
2006-01-23 17:51 ` C H Forsyth
2006-01-23 17:46 ` David Leimbach
2006-01-23 20:08 ` Ronald G Minnich
2006-01-23 18:46 ` Skip Tavakkolian
2006-01-24 2:22 ` Latchesar Ionkov
2006-01-24 8:37 ` Charles Forsyth
2006-01-24 9:41 ` Charles Forsyth
2006-01-24 10:04 ` Charles Forsyth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060125014026.GA9487@ionkov.net \
--to=lucho@gmx.net \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).