Date: Wed, 27 Jul 2011 13:18:33 +0300 From: Mikhail Kupchik <mikhail.kupchik@gmail.com> To: freebsd-ports@freebsd.org Subject: Writing large files on fusefs-ntfs mounted partition returns random errors EIO, ENOENT Message-ID: <CABF8sJ-hE8n=3pFone8UYHnxRi4Cga1Amwy6edWtT=iBSeh7vA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABF8sJ-hE8n=3pFone8UYHnxRi4Cga1Amwy6edWtT=iBSeh7vA>