keithtmc123 / macfuse

Automatically exported from code.google.com/p/macfuse
Other
0 stars 0 forks source link

MacFUSE Performance... #143

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I noticed, atleast with NTFS-3G MacFUSE performance is pretty sad.  This 
appears to be because 
MacFUSE is using a too-small-blocksize to talk to the FUSE clients.  I haven't 
yet done a detailed 
analysis and profiling though.  I'm not sure if this is an artifact of 
/dev/fuse being a VCHR device 
instead of a VBLK.  Although I *think* Linux FUSE implements it as a VBLK too.  
I haven't been using 
the Linux FUSE variant either though so I'm not sure if it has the same slow 
performance.  

For comparison dd a file to a HFS+ drive and one to a NTFS or other FUSE 
device.  If you watch 
iostat you'll see a huge TPS on the FUSE backing disk.  Now like I said I'm not 
entirely sure if it's the 
kext causing this or the FUSE client but it's posting a lot of small writes.

Original issue reported on code.google.com by gnu...@gmail.com on 11 Apr 2007 at 11:24

GoogleCodeExporter commented 8 years ago
Did you try looking at the MacFUSE FAQ?

Original comment by si...@gmail.com on 12 Apr 2007 at 5:02

GoogleCodeExporter commented 8 years ago
Ntfs-3g isn't optimized yet and if an application uses small block size I/O (or
intensive metadata update, etc) then ntfs-3g ends up doing a significant amount 
of
redundant work due to the lack of any caching, etc. Here are some write speeds 
as a
function of the used block size with dd:

 256 =>  3.1 MB/s
 512 =>  6.2 MB/s
1024 => 12.0 MB/s
2048 => 22.4 MB/s
4096 => 40.3 MB/s

The result is pretty much close to linear as expected.

Original comment by sz...@ntfs-3g.org on 12 Apr 2007 at 3:25

GoogleCodeExporter commented 8 years ago

Original comment by si...@gmail.com on 13 Apr 2007 at 3:59