0

Can a userspace program interact with the concrete file system(not VFS). What i have got is, that VFS allow linux to treat all file systems alike and gives a abstracted api to user space.

I want to achieve a condition where a custom file system should be able to give a api for read, write and erase on disk(SSD) at page level usable at userspace.

For which i will need to have a method to achieve interaction to the concrete file system bypassing the VFS.

  • 2
    Out of curiosity, why would you want to bypass a most comfortable level of abstraction such as VFS? – lgeorget Jun 3 '14 at 9:33
4

The only point of entry for filesystem interactions is the mechanism of system calls, which, in turn, relies heavily (if not exclusively) on VFS.

If someone wanted to create a filesystem that is not relying on VFS, that person would be forced to implement a new set of I/O system calls which would directly interact with the Linux block level.

This is neither elegant nor portable. Besides being a nightmare to implement, debug and maintain, this custom filesystem would be accessible only by applications that use this set of custom system calls. Such approach throws any notion of portability out of the window.

So to answer your question: Yes, it is possible by implementing a new set of system calls, but the only userspace clients of such filesystem would be your own applications. For anything more portable than that, you have to work with VFS.

Edit:

I saw your earlier question about implementing a high-performance key-value storage system for SSDs which I believe led you to consider this approach. I'd like to add two things:

  • VFS is not a bottleneck. It routes the I/O operations to the Linux block level in a very efficient matter.
  • The usability of an application that requires kernel patching (with code of questionable quality) is extremely low. Unless you are writing this system explicitly for your own personal use, I would suggest exploring other possibilities before attempting to optimize things within kernel.
0

Other than the “erase on disk”, which would be a ioctl(), that looks a lot like either:

  • Read/write the pages on the block device
  • Read/write the pages on a given file

which you would both do using lseek + read/write at proper page size.

(you could do pread/pwrite if you prefer to provide everything on one syscall, but it's equivalent)

0

Following on Low level disk i/o on linux, you can implement your own code to access a filesystem with a program that accesses the block device directly. This is very likely to be slower than the filesystem driver in the kernel (which is accessed through the VFS layer — that's what the VFS layer is about). It's possible, and it's useful for some use cases (e.g. forensics, or accessing filesystem types that aren't supported in the kernel), but it's the wrong approach for your use case.

  • You can generally get away "easily" with direct reads, but the proper handling of direct writes from user-space would be very problematic. It would cause a grave performance hit since you'd have to lock the block device on each write to avoid race conditions and data corruption on concurrent access attempts. – dkaragasidis Jun 4 '14 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.