linux-kernel - Re: [PATCH 0/7] OMFS filesystem version 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Apr 2008 16:23:18 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	me@...copeland.com
CC:	szaka@...s-3g.org, miklos@...redi.hu, hch@...radead.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/7] OMFS filesystem version 3

> >  > 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.

Fuse has two different APIs.  For the "high level", path based one,
this is true.  The "low level" one is very similar to the one provided
by the VFS.

On the low level interface, when the ->lookup() method is called, it
will provide a "nodeid", which is just a per-inode unique cookie (not
the same as st_ino).  It can be a pointer to the private inode data
for example, and in the ->forget() method this private data can be
freed.

> >  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.

And I think the VFS is great.  Undoubtedly kernel programming has it's
own charm, and I definitely don't want to scare you away from that.
Merging into mainline is a great reward, which must be erned the hard
way.  The debate is just part of that ;)

I also want to dispel any myths surrounding fuse, because those help
nobody.

Miklos
--
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/