When responding to a read request that is asking for more bytes than the file contains, you can simply return all of the available bytes, and a return status that indicates EOF. Since this is your filesystem, the way in which storage for the filesystem is allocated is purely up to you. You make the rules for that, and all of it is concealed from the kernel, and other applications. That is the whole point of a filesystem. The abstraction from physical storage to files and directories makes everything look the same at some level. So, when you say 'I have to read and write blocks', that restriction may apply to your filesystem low-level driver, but should be invisible to the kernel and any applications that access your virtual files. The requirement to read blocks of data in standard chunks originates from the nature of physical storage media and the associated electronics. Filesystems were created to make application programming unconstrained by this characteristic. For reasons of efficiency (which may defined in different ways), you may elect to use the physical block nature of media access in any way that suits the purpose.

To answer your final question, files are accessed by read operations as a request for 'n' bytes, starting at the current seek position. The seek position should be automatically adjusted as appropriate after each read() or write() operation, or in response to seek() system calls. The number of bytes, 'n', is specified as a parameter in the read() or write() system call, made by the application program accessing your virtual files. A request for 'n' bytes may cause your low-level media access to span more than a single physical block, but this should be invisible at any layer above your filesystem driver.

--- rod.

Hmm, i see.
Well thanks for that clarification. I've decided to just read 512 Bytes from wherever the offset is.

When a user application asks for less than 512 bytes, you will overrun the supplied buffer if you assume that you will always return 512 bytes. This will almost certainly cause Bad Things.
--- rod.

You're right, there is a potential problem, but i'm asked to do this, to read blocks only. I'll see what happens with the other parts of the assignment. I have to reassess the whole thing. I'm not even sure if these block methods will be used by fuse anymore.
I'll keep in touch if anything comes up.
Thanks for the help.

Hi guys.
I have a problem for which i cannot find a solution. The FUSE file system has a callback function:
As i've read, the df command uses this functions to get the file system statistics. The problem is, how do i implement this function?

I can think of two ways:

1- To do what the FUSE example does, call statvfs (...) inside this function, passing these args. But i'm thinking this wouldn't work. Aren't blocks logical partitions? The statvfs system call wouldn't know my file system's partitioning, so it would print the ext2 stats...

2- The other way is that i fill the statvfs structure's data, setting my block sizes, free blocks... But the one problem i find here is: How the heck am i gonna fill the fsblkcnt_t and fsfilcnt_t types? These are syst/types.h types that i have no clue about what they're supposed to be. The functions that i've implemented to count free blocks, bla bla... return ints and shorts!

So, any clues?

Thanks alot!

Well, since not all fields in struct statvfs are meaningful, you can probably safely put zeros or some other 'ordinary' numbers there (ie avoid 'boundary' condition numbers, like -1, 32767, 32768, etc). To be even easier on yourself, you could simply return ENOSYS, indicating that your filesystem does not implement this function.
--- rod.

But i need to implement those. They have key information like the size of the file system and number of free blocks.
And chance i can make it happen?

Okay, then put meaningful numbers in all of the fields, if such numbers exist. Try it out and see if the number returned by the likes of df make sense. fsblkcnt_t and fsfilcnt_t types are integer types, probably long ints. For your small filesystem, even the smallest integer type can represent the maximum values you will require.
--- rod.

ok then. I though ints won't work. It wouldn't compile or something.

Thanks.

When I say 'integer types', I mean that in a generic sense; they are not floating point types, characters, pointers, structures, unions, enums, or whatever else I may have forgotten. As such, they should cast without loss of precision. If the compiler makes a complaint about word size conversion, you can make an explicit cast to satisfy the compiler.
--- rod.

I actually assigned integers and never compiled.
I handed the assignment incomplete, so that's that.

Thanks for all who helped me understand FUSE better, especially you theNbomr. I really appreciate it.