Re: [Ocamlfuse-devel] Missing features

[Goswin v. B. <bre...@in...>]

Vincenzo Ciancia <ci...@di...> writes:

> Il giorno gio, 05/04/2007 alle 19.56 +0200, Goswin von Brederlow ha
> scritto:
>> - no create() binding, newer kernels use that and it might be nice to
>>   add
>
> Ok, will do this ASAP, thank you for input.

This one is new.

>> - 'mknod : string -> int -> unit' is missing the 3rd argument for the
>>   major/minor of device special files
>
> Was it introduced recently? I have lost the contact with fuse in the
> last months, maybe the whole interface has to be updated to a newer fuse
> version.

The ocamlfuse code say it uses fuse 2.2. I have libfuse2 2.6.3
installed:

/usr/include/fuse/fuse.h:
/* IMPORTANT: you should define FUSE_USE_VERSION before including this
   header.  To use the newest API define it to 26 (recommended for any
   new application), to use the old API define it to 21 (default) 22
   or 25, to use the even older 1.X API define it to 11. */

But I would guess mknod had always had that third argument. It is
optional though, it only has meaning when creating a block or char
special device.

>> - 'fopen : string -> Unix.open_flag list -> int option;'
>>   Fuse open() can return an arbitrary file handle in the struct
>>   fuse_file_info which is passed to to all file operations
>>   (read/write/flush/release/...). The file handle is an uint64_t so it
>>   is big enough for 64bit inodes, pointers or block addresses for
>>   large disks.
>
> So you say that I should change fopen to return int64 option? This can
> be done of course. Otoh, it would be better if fopen could return an
> arbitrary type but that would make the entire record type parametric -
> and I would have to solve next point:

I think a better solution would be to have 2 fuse modules. Like Unix
and Unix.Largefile.

The simple one would have open, read, write with and int like now.

The more complex one would have open return an arbitrary value or an ocaml
version of fuse_file_info and pass that to read/write.

> In your other e-mail, you ask what do I use for I/O. I use operations in
> the Largefile package, which are fast and nonblocking - the interface of
> the read and write functions in ocamlfuse is designed to make it easy to
> use the Largefile package, see fusexmp.ml for an example and the type of
> buffer in the beginning of Fuse.mli. Perhaps your concerns where about
> blocking I/O but I can assure you it's nonblocking in recent (>= 3.08 at
> least) versions of ocaml.

Ugh? By default it should be blocking unless you open with
O_NONBLOCK. And then the read/write returns when it cant read/write
enough data directly. But it does not continue reading/writing in the
background afaik.

With libaio you fire off all your reads and/or writes and then you can
check or wait for completions to come in. You can keep working between
fireing off the request and the completion and the kernel will do its
thing in the background.

I plan to have data split across multiple physical disks so when a
read/write comes in it is likely to involve multiple FDs that should
all read/write in parallel for maximum throughput. From a theoretical
point it is the difference between 40MB/s and 200MB/s. If I get
100MB/s I'm happy, if I get 20MB/s I'm sad.

> Thanks again, and don't hesitate to contact me whenever you want.

How was your trip?

> Bye
>
> Vincenzo

MfG
        Goswin