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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
