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]

Message-ID: <Pine.LNX.4.61.0804181958560.29728@dhcppc2>
Date:	Fri, 18 Apr 2008 20:35:48 +0300 (MET DST)
From:	Szabolcs Szakacsits <szaka@...s-3g.org>
To:	Bob Copeland <me@...copeland.com>
cc:	Miklos Szeredi <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

On Fri, 18 Apr 2008, Bob Copeland wrote:
> 
> 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.

I also don't advocate any solution, only interested in the FUSE myth 
busting and making it easier to use and develop for, i.e. having the best 
possible performance with zero effort.

I checked both solutions quickly, I think they are nicely written.

The kernel driver had 30 MB/s with 10% CPU usage, the FUSE version had 
6 MB/s with high I/O waiting.

The major reason seems to be that the FUSE version reads heavily from the 
block device during pure write operations, while the kernel driver never. 
There can be several non-exclusive explanations.

One of them, as you wrote, the functionality is not exactly the same, the 
FUSE one does more. If it's relevant or not, you should know. If anything 
is involved with reading from multiply places regularly then it's relevant.

Moreover when you're writing to a block device from user space then the 
size and position of the block should be page aligned, otherwise you end up 
doing unwanted synchronous reads instead of the believed asynchronous 
writes. Solving this issue for the most common cases resulted a sometimes 
over 10 fold write speedup in ntfs-3g. But of course it would be nice if 
the kernel just provided this for everybody.

Btw, mkomfs.c is missing a '#define _FILE_OFFSET_BITS 64' which is needed 
to open LFS files.

        Szaka

--
NTFS-3G:  http://ntfs-3g.org
--
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/