From: "Bob Copeland" <me@bobcopeland.com>
To: "Szabolcs Szakacsits" <szaka@ntfs-3g.org>
Cc: "Miklos Szeredi" <miklos@szeredi.hu>,
hch@infradead.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/7] OMFS filesystem version 3
Date: Fri, 18 Apr 2008 09:51:03 -0400 [thread overview]
Message-ID: <b6c5339f0804180651m2a291755ke093bda3bea1d2b4@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0804181302180.29728@dhcppc2>
On Fri, Apr 18, 2008 at 6:30 AM, Szabolcs Szakacsits <szaka@ntfs-3g.org> wrote:
> On Sun, 13 Apr 2008, Bob Copeland wrote:
>
> > I don't have hard numbers, but anecdotally my FUSE version is quite
> > a bit less performant. That's no criticism of FUSE - I just haven't
> > put the time into optimizing and adding various caches.
>
> Thankfully you need none, it's already there by FUSE and the kernel. The
> trick is exactly that you can have the kernel performance and the left is
> moved to user space with typically negligible performance overhead which is
> usually well compensated with faster delivered new features and bug fixes.
Correct me if I'm wrong, but one place where caches seem necessary is for
lookup. My file system already has an inode number; my understanding
is that the kernel inode cache and dcache are caching the FUSE inode by
filename and its hashed inode number.
In FUSE, on open, I'm passed a filename which I then have to resolve into an
inode # via my own lookup. The VFS does the path_lookup as part of sys_open,
and since I get to put private data into the struct inode, I'll generally
already have the block # and various other info in the dcache by the time
open is called.
Also, if you stuff inode data into the private fh field in fuse_file_info,
you need to be sure that any subsequent lookups always return the same
inode structure, otherwise a thread doing ftruncate vs one doing truncate
will cause issues. So I created an internal dcache to solve those two
problems.
> I noticed that the OMFS kernel driver supports only the USB interface and
> the FUSE one both the network and the USB one. Isn't it possible that you
> compared the performance using the USB with the kernel vs the much slower
> and lower latency network with FUSE?
Nope, that's not possible, sorry. Both require use of USB. lkarmafs and
omfs_fuse aren't the same thing.
> If you did use the USB interface with FUSE then what exactly do you mean by
> "quite a bit less performance" in numbers and workloads? What you did, how
> long it took using what CPU?
Like I said it was anecdotal (copy 20 gigs of X) in both. I'm sure a
good portion of it is my fault, such as doing unnecessary malloc & copies
in omfs_fuse. I have put exactly zero effort into making it fast so far.
BTW, I hardly intended to start a huge VFS vs FUSE debate. I think FUSE
is great. I'm not sure it's the right fit for this, is all.
--
Bob Copeland %% www.bobcopeland.com
next prev parent reply other threads:[~2008-04-18 13:51 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-12 22:58 [PATCH 0/7] OMFS filesystem version 3 Bob Copeland
2008-04-13 0:03 ` Andrew Morton
2008-04-13 3:33 ` Bob Copeland
2008-04-13 3:55 ` Andrew Morton
2008-04-13 4:41 ` Bob Copeland
2008-04-13 8:01 ` Christoph Hellwig
2008-04-13 8:20 ` Andrew Morton
2008-04-13 8:28 ` Christoph Hellwig
2008-04-13 10:37 ` Miklos Szeredi
2008-04-13 21:15 ` David Woodhouse
2008-04-13 22:44 ` Andrew Morton
2008-04-13 22:49 ` Alan Cox
2008-04-13 23:10 ` Andrew Morton
2008-04-14 1:32 ` Bob Copeland
2008-04-14 5:48 ` Andrew Morton
2008-04-14 8:16 ` Alan Cox
2008-04-14 8:36 ` Andrew Morton
2008-04-14 8:41 ` Christoph Hellwig
2008-04-14 14:20 ` Chris Mason
2008-04-14 16:36 ` Bob Copeland
2008-04-14 16:51 ` Alan Cox
2008-04-14 17:18 ` Bob Copeland
2008-04-14 17:22 ` Alan Cox
2008-04-14 20:29 ` david
2008-04-18 13:13 ` Szabolcs Szakacsits
2008-04-14 20:55 ` Jeff Garzik
2008-04-14 21:11 ` Andrew Morton
2008-04-14 22:32 ` Evgeniy Polyakov
2008-04-14 23:21 ` Andrew Morton
2008-04-14 23:09 ` SL Baur
2008-04-14 23:24 ` Andrew Morton
2008-04-14 8:30 ` Xavier Bestel
2008-04-14 8:43 ` Christoph Hellwig
2008-04-14 8:44 ` Andrew Morton
2008-04-14 9:08 ` Christoph Hellwig
2008-04-14 9:09 ` Christoph Hellwig
2008-04-14 9:21 ` Andrew Morton
2008-04-14 10:09 ` David Woodhouse
2008-04-14 10:22 ` Andrew Morton
2008-04-14 10:36 ` David Woodhouse
2008-04-14 11:16 ` Christoph Hellwig
2008-04-15 15:16 ` Adrian Bunk
2008-04-15 16:57 ` Christoph Hellwig
2008-04-15 18:34 ` Andrew Morton
2008-04-15 18:53 ` Alan Cox
2008-04-15 20:02 ` Andrew Morton
2008-04-15 19:58 ` Alan Cox
2008-04-15 21:46 ` david m. richter
2008-04-15 19:24 ` Adrian Bunk
2008-04-15 20:11 ` Andrew Morton
2008-04-15 20:27 ` Adrian Bunk
2008-04-14 7:25 ` Miklos Szeredi
2008-04-14 7:49 ` Andrew Morton
2008-04-14 8:11 ` Miklos Szeredi
2008-04-14 8:11 ` Anton Altaparmakov
2008-04-14 8:26 ` Miklos Szeredi
2008-04-14 9:42 ` Jamie Lokier
2008-04-14 9:58 ` Miklos Szeredi
2008-04-14 11:05 ` David Woodhouse
2008-04-14 12:50 ` Miklos Szeredi
2008-04-14 11:55 ` Jamie Lokier
2008-04-14 11:57 ` Christoph Hellwig
2008-04-14 12:26 ` Miklos Szeredi
2008-04-14 22:35 ` Jamie Lokier
2008-04-15 11:33 ` Miklos Szeredi
2008-04-15 15:23 ` Jamie Lokier
2008-04-17 1:08 ` Szabolcs Szakacsits
2008-04-17 6:50 ` Jamie Lokier
2008-04-17 8:17 ` Miklos Szeredi
2008-04-14 0:45 ` Bob Copeland
2008-04-14 7:35 ` Miklos Szeredi
2008-04-18 10:30 ` Szabolcs Szakacsits
2008-04-18 11:52 ` Jamie Lokier
2008-04-18 12:20 ` Miklos Szeredi
2008-04-18 12:57 ` Jamie Lokier
2008-04-18 16:01 ` Miklos Szeredi
2008-04-18 16:15 ` Jamie Lokier
2008-04-18 13:51 ` Bob Copeland [this message]
2008-04-18 14:23 ` Miklos Szeredi
2008-04-18 14:43 ` Bob Copeland
2008-04-18 17:35 ` Szabolcs Szakacsits
2008-04-18 17:48 ` Bob Copeland
2008-04-18 12:46 ` Szabolcs Szakacsits
2008-04-13 9:04 ` Alan Cox
2008-04-13 10:00 ` Pavel Machek
2008-04-15 3:14 ` Erez Zadok
[not found] <14725485.776281208170999085.JavaMail.szaka@kolumbus.fi>
2008-04-14 12:46 ` Szabolcs Szakacsits
2008-04-14 13:15 ` Anton Altaparmakov
2008-04-14 16:12 ` Szabolcs Szakacsits
[not found] <10224488.783261208172602425.JavaMail.szaka@kolumbus.fi>
2008-04-15 0:11 ` Szabolcs Szakacsits
2008-04-15 15:05 ` Adrian Bunk
[not found] <aiwLk-3mc-3@gated-at.bofh.it>
[not found] ` <aiwLk-3mc-5@gated-at.bofh.it>
[not found] ` <aiwLk-3mc-1@gated-at.bofh.it>
2008-04-16 9:56 ` Bodo Eggert
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=b6c5339f0804180651m2a291755ke093bda3bea1d2b4@mail.gmail.com \
--to=me@bobcopeland.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=szaka@ntfs-3g.org \
/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).