Hi guys. I have a new assignment to work on and i need your help. It involves creating a new file system with FUSE. I know what I need to do to get it done (at least i think i do). What I'd like to know is how FUSE works.
I've read some stuff on it, basically from sourceforge and the IBM website, but i can't find any other good references on it. What i want to know is when do the functions that i implement (read, write...) get called. And why do i need to use system calls only in my implementations and not library functions (or am i wrong assuming that?). Plus, what does FUSE do when it takes over my program with fuse_main?

Thank you.

Oh, i'd like to add somehting else too.
The functions i want to implement don't have the form that is required by the fuse_operations function pointers. Do they have to be of that form or should i just creat my own struct fuse_operations?

Thanks.

The functions that you create are defined by the general form of a filesystem interface. Normally, a type of filesystem is a kernel module, which provides the go-between from the kernel and the hardware, or wherever the files are in some physical sense. The kernel accesses the filesystem on behalf of the a userspace application that has made some system call to access the filesystem (such as open(), read(), write(), seek(), close(), etc). The semantic behavior of the functions that the filesystem module provides defines the functionality of the filesystem. In the case of FUSE, which is itself the kernel module, it simply provides hooks for a userspace application to provide the functionality that a kernel-mode module would normally provide to instantiate a filesystem. You must provide the interface functions in the form required by FUSE (which is beholden to the format required by the kernel). The functions will be called asynchronously by the kernel, through the FUSE layer, in response to userland accesses to your virtual files and directories.
FWIW, I think the examples that the Fuse package provides are a bit confusing. I think a better example would be any long-running application that has a data-set that other applications would want access to. This might be some kind of financial application that maintains transaction records and status information, or some kind of control system that has runtime data related to the state of a machine, as a couple of examples. The internal database that is part of said long-running application could be made accessible to other applications through a virtual filesystem. That way, any tool that can open and read files can potentially get at the data, and possibly even modify it, depending on the implementation of the virtual filesystem that is embedded into the long-running application. The format of the virtual files in the virtual filesystem could be tailored to particular pre-existing classes of applications. For instance, the virtual files named 'something.csv' would be formatted as comma-separated variables, ideal for importation by most spreadsheets.
Hope this helps.

--- rod.

They get called when operation is performed on your file system. Let's say you mount your fuse fs in /mnt/myfs, cd to there and perform the ls command in that location (on your file system). The fuse kernel module (which is responsible for handling that filesystem) will call appropriate functions as it would ask the regular file system driver. But it will call your userspace function instead. You have to refer to the documentation to figure out actual parameters and return values.

I've never heard of such a limitation. You might be wrong on that (not 100% sure though), from what I remember I've successfully called system calls from the libraries linked to my file systems.

Sometimes it's not possible to implement all functions. Let's say your fs is read-only. Then you can not implement write function, however you should handle it somehow.

Thanks for the info guys. Both of you were very helpful.
But i have a couple of questions. First, about the system calls, so can i use fopen() to open a file? Cause the implementations i saw used open() and similar things, like memcpy()...all system calls.
Second and the more important, if i need to use functions of the defined format, then this will create a problem. My assignment requires me to use functions of certain formats, example:So instead of using the read() defined in the fuse_operations structure which requires a fuse_file_info structure as parameter, i need to use the above one. How am i supposed to do this? Is there a mistake here? The professor strictly wants the implementation to be in the format he specified.

Thanks.

It sounds like some simple wrapper functions are all you need to adapt what you've got to the requirements of FUSE. This would be a standard way of implementing this sort of thing.
--- rod.

You can (from userspace) use fopen(). What happens (in userspace), when a program calls fopen(), the C library translates it to a series of internal functions, which invariably ends up calling the kernel’s sys_open() system call.
The format/signature of the callback functions specified by the FUSE API is constant (thus it’s an API). You can have internal functions with your signature, and for the callback function itself, you’d use a wrapper which calls this internal function (in the internal workings of your filesystem, you’d have assigned an id for each opened file or something similar).

ok, so if the ones required from me are wrapper functions, then i have to implement the underlying API too, right? But now, when my program calls fopen(), it wouldn't call the wrapper one would it? It would just call the callback function open() (the API one).
So what's the use of this wrapper function?

I think you misunderstand.

You say you have an existing, immutable, set of functions, or some API that defines how your filesystem is accessed. The FUSE package, however, requires a different set of functions to be provided to implement your virtual filesystem. The wrapper functions simply transform what is wanted by FUSE into what your existing functions/API provides. Often, this is as simple as re-arranging arguments, or converting argument types.

--- rod.

I'm having a hard time understanding the last part of what you said. What do you mean "transform what..."?
Isn't the wrapper function my_open() call the FUSE's function open()? But when a program calls open and this program is passed as an argument to fuse_main, what exactly gets called?

Okay, now I think you don't really understand the whole concept of creating a virtual filesystem using fuse. Or, I don't understand your question. So I will try to rephrase what I think I've already explained, and what I think you've stated.

1. You have a set of functions that in some way defines the semantics of a filesystem. "The functions i want to implement don't have the form that is required by the fuse_operations function pointers". So you have some functions that have some other form, not specified.

2. You want to know how these functions that implement your virtual filesystem fit into the bigger picture. How do the functions in your virtual filesytem get called?

3. You want to know how the funtions you have written or will be writing can be made to fit the requirements of FUSE.

To understand the answer, try to imagine what happens when any arbitrary application wants to open a file, or do any other operation related to a filesystem. The application makes a system call, such as open(), read(), write(), etc. The kernel receives the call, and related arguments, and sees what branch of the filesystem is being referred to. From this, it knows what driver is responsible for the type of filesystem, based on the position relative to all the current mount points. Knowing this, it dispatches the appropriate function with that driver, to perform the action origianlly requested by the userland application. This is where your virtual filesystem comes in. If the mountpoint for your virtual filesystem is a parent directory of the file of directory referred to in the origianl system call, then the function that the kernel will call is one of the ones in your implementation of your filesystem. It does this through one layer of indirection, since it first calls the fuse kernel module, which then calls your userspace function(s). Now, when the kernel, via fuse, wants the filesystem driver to perform the appropriate actions, it calls the driver's relevant function, passing a predefined set of arguments, and expecting a return value of some predefined nature. If the functions that you have implemented don't conform to this standard (and I cannot imagine why you would have done it that way...), then you will have to create a set of functions that do conform. These are the wrapper functions, and their only purpose is to do whatever they need to, to get/put the kernel's arguments into your driver callbacks in the correct format.
Your set of callbacks are part of some program that you write, which presumably runs for some extended period. They provide the underlying functionality of a filesystem. Other programs will see the files and directories that your filesystem instantiates (even though they may not be real files, in the sense of existing as non-volatile entities on magnetic, optical, or NV memory). Your filesystem will exist only for as long as your program runs. The filesystem will magically spring into existance when you call the fuse_main() function, and will provide services to the kernel, indistinguishable from any other filesystem driver.

I hope this gives you a clearer picture.
--- rod.

Ok. I now understand how the filesystem functions, and what the kernel does.
So in my case, since I create a virtual file system, the FUSE package's functions are the ones getting called by the kernel through the FUSE's kernel.
Now, the functions that i have to create, i.e. the ones that read blocks of data, will be embedded inside the Fuse's constant API functions. The API functions, referenced by the fuse_operation structure, will be the wrapper ones and call my callback functions. Is this correct?
See, the way i was thinking is that, my functions were supposed to call the API functions. So that created confusion.

Ok, so now the functions that i write CAN use C lib functions and system calls right? Cause i need to read and write blocks of data only, were each block is 512B, from a VFS of 4MB, implemented as a file (i created it using the dd command).

P.S. I really appreciate all the help guys. It's just that i'm totally new to this.

Yes, that sounds correct. I think.
--- rod.

ok, i have a small question.
I have a virtual file system of size 4 MB. It's composed of blocks of 512 Bytes each. I have an array that keeps track of whether the block is used or not.
I am confused about something though. I have to read and write blocks. The problem i have is with reading a block. Let's say i have a file that occupies 1 and a half blocks. Now the half block not used will be wasted right? It can't be used. Ok, now if i have a read operation on this file with offset half a block, and the amount to be read is 1 block. How would this work? Am i supposed to read the two blocks and copy to the buffer both halves (from 0.5 block to 1.5?)? Or should i just read 1 KB of data disregarding the division of the two parts of this data (i.e. without caring they are on diff blocks).
I think i am required to do the second, but i'm not sure. For example, how would this work with a normal file system? Would the operation read blocks of data as in block 1 and block 2... or as in 512 Bytes from anywhere to anywhere?

Thanks.

Typically, in the fs design, you can not have a cluster occupied by 2 or more files. Based on your filesystem purpose you should choose the proper cluster size according to the total size of you filesystem and some other means. BTW, this should be separate topic, it's not really related to FUSE.