Hi, I finally make the ublio code publicly available at
http://mercurial.creo.hu/repos/libublio Instructions to graft it onto ntfs-3g (HEAD): - patch source with attached patch ntfs-3g-ublio.diff - get libublio - put ublio.c into libntfs-3g, header files into include/ntfs-3g (optionally adjust ublio_conf.h but I don't think you'll need to do that) Then compile the code. Now you can use ntfs-3g on FreeBSD, both with regular files and disks. You can enforce the usage of the ublio layer for regular files (or on Linux) by adding NTFS_USE_UBLIO=1 to the environment. There are some other ublio parameters you can set via env vars, grep for UBLIO in unix_io.c to see them (and browse through ublio.h to understand them). In a nutshell, defaults are: use sync I/O (don't keep around dirty data), use a cache of 12 items. For comparison, I also ported fjoe's lean-and-mean aligned I/O layer to ntfs-3g. To compile an ntfs-3g with this included, do: - patch source with attached patch ntfs-3g-ublio.diff [needed only on FreeBSD] - patch source with attached patch ntfs-3g-enforce_fbsdio.diff - get libntfs/freebsd_io.c from linux-ntfs tree (I used rev 1.2) and patch it with attached freebsd-io.c-pio.diff If you compile this, then fjoe's I/O backend will be used (both on FreeBSD and Linux). To enforce block (512) aligned I/O, set the FORCE_ALIGNED_IO env var. So now you can play with both ublio and fjoe backend, both on FreeBSD and Linux, both with regular files and disks. However, to see real-life performance, I think the most useful test environment is when you use a disk with FreeBSD. However, my naive testing attemps didn't yield any consistent result. I experienced that namei operations are rather slow. I blamed it on the lack of name cache support in fuse4bsd, but on Linux disabling the name (entry) cache didn't make any visible difference. To get rid of this bottleneck, maybe it would be useful to test I/O operations within one file (eg., use it as a database backend, or make it an fs image and mount that and do file operations within that...). For usual fs operations (moving some files around), it seemed that ublio has a relatively big pure overhead (ie., when cache is disabled), contrary to fjoe backend, but caching yields a noticeable improvement. In general, results oscillate wildly and I can't yet come to a worthful conclusion. Eg. I got the following results when I tested raw throughput by catting a file of 100 megs: mounted throughput (megs/sec): ------------------------------------------------------------ ntfs-3g w/ ublio, 1024 cache entries 0.5 ntfs-3g w/ ublio, 128 cache entries 1 in-kernel ntfs driver 3 ntfs-3g w/ fjoe backend 3.5 ntfs-3g w/ ublio, no cache 4 ntfs-3g w/ ublio, 12 cache entries 10 OTOH, I also saw the in-kernel ntfs driver to complete a find(1) over a directory tree of twothousand-some files in 1-2 seconds and ntfs-3g in 3-4 minutes. The gap is too big to imply anything from it... The problem is that the media I can use for testing is crappy. I can use two kind of things: md devices (similar to loop devices of Linux) and usb sticks. And the kernel code for these is crap. I/O on md devices is magnitudes slower than on the backing file (7-70 times) [I/O as is, without ntfs-3g or any other overlay]. Using usb mass storage intensively yields deadlocks and panics (to tell the truth, these might have been caused by an upper layer like fuse4bsd, nevertheless statistics suggests the mass storage driver is to be blamed for these). Duh. So the code should be tried with hard drives on FreeBSD or find a way in Linux for doing uncached I/O on a device (it does interest me, please tell me if you know a way for it). Csaba ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
