0

When mounting an NFS filesystem, all data handling goes through the nfs client. How can I write my own handlers to use something other than NFS?

An alternative would be a localhost NFS server but that seams awfully inefficient

Edit

Example of what should happen

Normally with a filesystem you get: app reads/writes filesystem, Solaris sees where it is mounted and if it is disk then it reads/writes the disk. If it is software mirror it reads and writes to the mirror software. If it it is NFS it reads and writes to a remote NFS server. I want it to read and write to a custom storage software instead of any of the above mentioned options.

Our storage software is for storing files that applications use, it is geared towards large or frequently replaced chunks of data that are not stored in a database. It also includes certain flexibility specific to our company.

Old/existing applications don't know about our new software. All they know to do is read/write a directory. We could tell Solaris that the directory was hosted on NFS and then the NFS server translates and connects to the storage software. We would prefer to tell Solaris about our new program which Solaris has never heard of and then teach Solaris how to talk to our program.

700 Software
  • 85,281
  • 83
  • 234
  • 341
  • You want an application to talk directly to an NFS server? Is that what you're asking? Any particular reason why? – Will Hartung Dec 06 '10 at 19:30
  • I would like a way to intercept data from existing apps that use files/filesystem. NFS client is just an example. I could write an NFS server and mount it that way, but the whole point is to mount data, not to talk to NFS. – 700 Software Dec 06 '10 at 19:33
  • 1
    Can you provide concrete examples of what you are expecting and explain why a localhost NFS server would do the job but in an inefficient way ? – jlliagre Dec 06 '10 at 20:17
  • You could mount an NFS filesystem and point it to a manually written NFS server. That NFS server would then interact with our handling software. However, that example requires that you run all the data through the NFS client, loopback interface. Those extra layers would be eliminated if I could put my code in the same position as the NFS client is in because it could use the data handling software without using the loopback interface, and I could skip translation to/from NFS. However, If I had a working NFS server in Java, I would take the less efficient route.. just to save development time. – 700 Software Dec 06 '10 at 20:24
  • Hmm, I still have little idea about what you are looking for. Are you looking for writing your own filesystem ? or just a custom device driver ? You failed to provide any "concrete" example of your expected usage. – jlliagre Dec 06 '10 at 21:34
  • See better example in edit. Sorry, it seems to confuse people when I don't clearly say *I want to accomplish this feature that NFS has accomplished: mounting a directory on a software instead of on a device* – 700 Software Dec 06 '10 at 22:08

3 Answers3

1

To me this sounds like you'd have to create a pseudo file system. Solaris uses VFS (Virtual File System), under which you can use different filesystems presented as one uniform structure to userspace. Wheither you mount a UFS or NFS or WHATEVER filesystem, users and applications can use filesystem-agnostic tools to interact with VFS.

That means that what you need to create a pseudo file system; a filesystem that manages to handle the vnode and vfs operations (VFS syscall interface), such as read(), write() etc and tie them, (decide what to do when someone opens a particular file etc), to a database-backend of your choice.

Read more:

http://developers.sun.com/solaris/articles/solaris_internals_ch14_file_system_framework.pdf

Sounds like a big task...

Regards, jgr

jgr
  • 3,914
  • 2
  • 24
  • 28
  • With our data storage software (kinda like a database but not exactly), the existing apps all have to be rewritten. But if we just mount the filesystem to a place that are device controls, then we get the best of both worlds.. The apps that use filesystems are unaffected and they get the advantages of our storage software. – 700 Software Dec 06 '10 at 19:58
  • Ok, so you have applications talking to your database. The database writes to a filesystem via Solaris VFS. Exactly what do you need to do again? Still clueless I'm afraid... – jgr Dec 06 '10 at 20:24
  • I need a way to save files to my database instead of directly to the hard disk. But I do not want to have to rewrite all the existing apps that currently use the filesystem. I am not using VFS. – 700 Software Dec 06 '10 at 21:12
  • If the application isn't time-critical, one way of doing it (easier) would be to not change the behavior of the application, i.e still writing to disk, then shove that data into the database via a 3:rd agent, that you'd have to write. It could be a daemon or bash-script or whatever, depending on the amount of data your application generates. Thats my thoughts. – jgr Dec 06 '10 at 21:28
  • It is important that the data is written synchronous. I edited my question. – 700 Software Dec 06 '10 at 22:09
0

You might want to look at some CIFS servers. Alfresco has JCIFS, which is a CIFS server library in Java. It lets you present resources as files, as if they're on a Windows system. So, that means that programs can "mount" these CIFS servers, and you can publish data from your Database via that mechanism.

I have not used it, but that sounds like what you want to do and perhaps something you may want to look in to.

There's also FUSE which lets you create custom file systems in "user mode" rather than having to hack the kernel. It works on Unix and Mac OS, there may be a Windows version as well. This can, in theory, do anything.

For example, there are instances that let you mount a remote system over SSH using a FUSE system. These tend to be written in C/C++.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
  • We don't use Windows.... For obvious reasons. [FUSE](http://fuse.sourceforge.net/) looks very interesting. Much better than writing an NFS translation server I think :P – 700 Software Dec 06 '10 at 22:39
  • If you're not doing wacky stuff at the file level, Solaris has full support for CIFS built in, so you may still want to consider the CIFS servers as well. – Will Hartung Dec 07 '10 at 01:40
0

NFS isn't about mounting a directory on software but mounting a remote share on a directory. Whether the storage device is remote or not doesn't matter that much, it is still through layers of kernel software. Solaris use VFS to provide the first layer. You should implement the underlying one. That would be quite a difficult task for someone already familiar with VFS. As you obviously are not familiar with writing kernel code, I would be very pessimistic about your project ...

What I would suggest you to do instead would be a simpler and less risky approach. Implement an interposition library that would intercept the application I/O code (open, read, write, close, and the likes or perhaps libc fopen, fwrite, you have to figure out what is the best location to interpose) and call your storage software instead.

Here is a simple example of the process: http://developers.sun.com/solaris/articles/lib_interposers.html

jlliagre
  • 29,783
  • 6
  • 61
  • 72