Re: [Ocamlfuse-devel] Missing features
Brought to you by:
applejack
From: Vincenzo C. <ci...@di...> - 2007-04-08 11:09:58
|
Il giorno dom, 08/04/2007 alle 03.32 +0200, Goswin von Brederlow ha scritto: > > Ok, will do this ASAP, thank you for input. > > This one is new. > You're right - time is scarce and things to do are many - I think that I should update the whole binding to very recent fuse, and the create method is one thing to implement, if you have time, make a list of all the changes, that will ease my work a lot, or else I will start just by implementing create. It is much more time consuming to identify interface changes than it is to implement those in the bindings. > 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. I remember that fuse didn't support special devices in 2.4 series but I might be proved wrong > I think a better solution would be to have 2 fuse modules. Like Unix > and Unix.Largefile. Well, maybe not, since the goal of the ocamlfuse layer is to mimic C as close as possible, so that the right thing to do seems to switch to 64 bit for the file handle size. > Ugh? By default it should be blocking unless you open with > O_NONBLOCK. > With libaio you fire off all your reads and/or writes and then you can > check or wait for completions to come in Ok, I thought you meant "nonblocking" in the ocaml sense: foreign calls to C are always blocking by default, but if you know they won't affect the ocaml runtime, or do proper locking, you can tag them as "nonblocking". In that case, your ocaml threads keep running while the system call is in progress. Then you can implement asynchronous operations in ocaml land very easily (and efficiently, since the ocaml runtime handles threads with minimal overhead). Maybe there is something I am forgetting here about libc, please forgive me if I will make you repeat yourself. > > 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. > Your operations (in particular, reads and writes) will be done in parallel by default, try that. I don't like how current scheduling is done (a new ocaml thread is fired for each operation) but it is easy to change, like almost everything in ocaml. By the way, in ocaml 3.08, the stat-alike calls where still not tagged as nonblocking, resulting in a stat over a dvd in fusexmp to block the entire filesystem process for some 10 seconds. I seem to recall this problem has been solved in recent ocaml versions, however it is easy to check, if not, I will add a non-blocking stat to the utility libraries of ocamlfuse. > > Thanks again, and don't hesitate to contact me whenever you want. > > How was your trip? > It was long... I had to travel for 11 hours on Monday and Wednesday, and the same on Saturday - hope to stay here some day now :) Vincenzo |