Very Slow Captive NTFS

[bluni]

I have a tri-boot with hda my nfs winxp install, hdb1-3 is gentoo and hdb4 is ntfs for vista. I have captive running and I can read/edit/write files, but sometimes it runs dog slow. For 10 seconds it will lock up whatever program is trying to access the drive (amarok, konqueror, mplayer, etc.). Eventually the program will wake up again, but most of the problems lie in just browsing the folders and files. Once a movie starts in mplayer or song in amarok, it won't skip, but browsing the filestructure and writing takes a while.

It particularly slows down firefox and thunderbird (I have soft links to the ntfs drive so I can have the same mail store in both(all three actually ) OSes). Any ideas how I can make it more responsive and overall faster? The drives don't spin down, so it's not normal spin up times or anything like that. Here's relevant specs:

* Two IDE 80 GB 7200 rpm drives - good condition (SMART tests, i guess i could do full disk fitness tests, but i never have the problems in winxp or vista)
* P4 3.0 Ghz w/ SMP (HT)
* 1 gig PC 2700 RAM
* 1 gig swap space barely barely touched
* ~x86 portage
* KDE 3.5, xgl, compiz, modular x
* emerge --sync && emerge -DNu world performed often
* 2.6.16-r1 gentoo-sources manual config with NTFS read and write support built into the kernel (they are left from before I learned the limits of the kernel NTFS "write" O_o )

Thanks for your help,

Brian

[kmj0377]

Unfortunately, captive ntfs is slow. It uses the Windows filesystem driver in the same way Wine does for Windows executables: it emulates required layers of Windows NT. It's different in that Wine only needs to replicate userspace parts of NT, whereas captive ntfs needs to do some kernel stuff too. All this emulation and translating Windows calls to Linux and Linux calls to Windows slows down the overall process.

[bluni]

Is there any way the native kernel NTFS write will ever do real NTFS writing? Or is captive the accepted answer?

I tech support systems (hence the tri-boot) for money on the side and you know a lot more if you do normal activities those operating systems, and I want to explore the wonderment that is Linux .

Thanks,

Brian

[kmj0377]

[ebichu]

Captive isn't emulating Windows calls - it's actually running Windows code (ntfs.sys), but it's running it in a user-space process. This is slow because every time some process accesses the NTFS filesystem a process context switch occurs for the 'captive' process to perform the filesystem operation and another process context switch back to the original process afterwards. Also there is more data being passed back and forth between user and kernel space than there is for a normal kernel mode filesystem.

The only way to speed captive up would be for it to support loading the Windows driver into kernel space (as is done for ndiswrapper), but I don't know how likely that is to happen!
_________________
Ebichu wa chiizu ga daisuki dechu!

[Parasietje]

IMHO, it is unlikely that Microsoft will ever open up the NTFS file system specifications. You could help spamming the "port25" website asking for this of course

To answer your question: Captive is indeed plain slow. Maybe you could renice the captive process? That way it would at least get more CPu power.

[kmj0377]