Hi,

I'm trying to run some batch processes on some large files stored on my NTFS partition, but an hour or so into it I'm getting some I/O errors.

First of all, in the /var/log/messages, I have a bunch of lines like this:

Nov 5 08:08:17 atheneum ntfs-3g[2835]: ntfs_attr_pread partial write (4294967296: 518508 <> 0): No such file or directory
Nov 5 08:08:58 atheneum ntfs-3g[2835]: ntfs_attr_pread partial write (4294967296: 960876 <> 0): No such file or directory
Nov 5 08:09:27 atheneum ntfs-3g[2835]: ntfs_attr_pread partial write (498466816: 3797776748 <> 0): No such file or directory

Those seem to appear long before the problems begin to occur, so maybe they have nothing to do with it.



There is another thing. I had a shell window open with the current path being somewhere on that NTFS drive. After a while 'ls' would return an error:

$ ls
ls: .: No such file or directory

Interestingly, the sequence
cd ..
cd -
makes it work again. Frankly, this is much more troubling. What could be happening here?


FreeBSD 6.3-PRERELEASE #3: Sat Nov 3 09:30:07 EDT 2007
fusefs-kmod-0.3.9.p1
fusefs-libs-2.7.0_1
fusefs-ntfs-1.1004

I mounted the NTFS drive with
env UBLIO_BLOCKSIZE=2097152 ntfs-3g /dev/da0s1 /mnt

The drive is an external (USB) Iomega 500GB.

Actually, these messages in /var/log/messages do seem to be correlated with the problem with "ls". Any attempt to open a file from the current directory will fail.

What is more interesting is that "ls .." fails, but "cd .." will work. I don't know if that's somehow specific to how cd works (i.e. if it caches directory structure somewhere), or not.

Hi!

Thanks for the bug reports Kristof.

I forwarded your problems to the FreeBSD maintainers. The first one may be solved by an upgrade to 1.1104. The second one must be FreeBSD specific.

Szaka

The problem about losing "." is a known issue and a solution is being worked on. It has to do with differences in the FUSE API implementation on Linux and FreeBSD (which depends on the kernel internals).

I had a similar problem related to the same issue, that is: read(2) returns with EAGAIN set (resource temporarily unavailable) when playing a song in XMMS and doing relatively intensive operations at the same time (not with ntfs-3g, but FreeBSD's filesystem).