Writing large files on fusefs-ntfs mounted partition returns random errors EIO, ENOENT

[Mikhail Kupchik]

Hello All,

Recently I've encountered the following problem: writing large (200MB+)
files into ntfs partition managed by fuse + ntfs-3g + libublio (on umass
device) yields random write errors, usually EIO or ENOENT.

Versions of the software:
1) Kernel: FreeBSD-8.2-RELEASE, i386, generic
2) NTFS-3G: 2011.4.12 external FUSE 27
3) FUSE kernel module: fusefs-kmod-0.3.9.p1.20080208_7
4) FUSE userspace libs: fusefs-libs-2.7.4
5) UBLIO library (userspace cache for block devices): libublio-20070103

How To Repeat:
1) Get USB flash thumbdrive (1Gb in my case)
2) Quickformat it in Windows ("format I: /FS:NTFS /Q") and unplug via tray
icon as usually
3) Plug USB flash thumbdrive to FreeBSD box
4) kldload /usr/local/modules/fuse.ko
5) ntfs-3g /dev/da0s1 /mnt/usb
6) dd if=/dev/random of=/usr/rndfile.bin bs=1M count=300
7) cp /usr/rndfile.bin /mnt/usb/rndfile.bin
8) After some time, cp exits with error message
cp: /mnt/usb/rndfile.bin: No such file or directory

USB subsystem is probably fine, because kernel-mode msdosfs and direct write
with dd(1) works without any problems.

I've tried to enable ntfs-3g debugging, and ntfs-3g works fine when it's
spends additional CPU cycles printing debug info. Looks like some race
condition. Writing into NTFS partition also works fine with ublio disabled,
when I/O rate is low.

IMO it looks like a problem in the fusefs-kmod or fusefs-libs, because
ntfs-3g code is well-tested on Linux and ublio code is well-tested on Mac.

Also I tried to hack ublio - add pthread locks, syncs after each write,
replace pwritev(2) with series of pwrites, add assertion checks. None of
these really helped, but ENOENT/EIO errors were relatively rarer, due to I/O
rate slowdown I suspect.

Right now I need someone who can confirm this problem in his/her environment
and look into fusefs-kmod code for race conditions, as I'm not good in
kernel hacking.