Download

Quick search

Rate this software

• Currently 0/5 Stars.
• 1
• 2
• 3
• 4
• 5

No. Votes

0

Linux

Windows

Mac

Mobile

Drivers

Scripts - DHTML

Web Developer Blog

Scripts and Applications

Simple TCP FUSE File System

Details

Simple TCP FUSE File System is a FUSE based networked file system. It consists of 2 parts. A network server daemon that is started on the (remote) host and a FUSE module running in user-space on the local host. Server component is launched via SSH and after client and server have communicated and created separate TCP connection for data transfer SSH link is shut down.
So, this provides somewhat the same functionality than sshfs, but security traded for speed. If security is not an issue, this is useful at least in the following situations: 1) Either machine is low-end. 2) The machines has important high-load application(s) running. 3) One wants to see real statvfs values.
Installation:
Client requires FUSE headers and libraries, server does not. Currently C99-capable compiler is needed to compile both client and server, but with little effort on the code, this requirement can be removed from the server component.
To compile both client and server, enter ``make all``.
Enter ``make client`` or ``make server`` to compile either component.
For developers/testers: Enter ``make debug`` to compile debug build.
After client compilation on "local" machine (where directory is to be mounted) and server compilation on "remote" machine (from where directory is mounted), move server component to a location that is on your PATH. In many cases entering command ``cp stfufs-server $HOME/bin/stfufs-server`` does the job. During initial testing, client does not need to be copied anywhere, but for permanent use it is good to be get somewhere in your PATH.
Usage:
These examples expect stfufs (client) is found in your PATH. During initial testing on stfufs source directory, use ``./stfufs ...``
In it's basic form, the usage is pretty same as with sshfs_:
``stfufs remote:[directory] mountpoint``
This instructs server try to bind on ports in range 13668 - 14658, on 10
port increment and if succeeds to bind on any, listen for client to connect
on that port.
For this to work, one must not have firewall to block on these ports;
stfufs-server do know when port is already in use, but does not know about
firewall blocking connections. Today, most of the systems (linux distributions, at least) have firewall blocking connections, so check with your system firewall configuration tool how to open the required port(s)
You can also define what port to use for connection:
``stfufs -c < portno > remote:[directory] mountpoint``
Now server tries to bind on given port and if succeeds, listens for client to connect. The above firewall rules apply.
There is also possibility to make the connection other way around:
``stfufs -b < portno > remote:[directory] mountpoint``
Now client tries to bind on given port and if succeeds, listens for server to connect. The same firewall rules apply, now on client machine.
In both connection directions, there is also a proxy option available. If this sounds too difficult/badly documented, skip over.
Example:
``./stfufs -c 2001 -p 127.0.0.1:2000 -d 127.0.0.1:/usr usr``
This informs server to bind on port 2001, but connection is made to localhost (127.0.0.1) port 2000. On that port, there is proxy pre-configured to connect to port 2001 on remote machine. This has currently mostly used for debugging purposes but there might be other uses as well.
And, for another direction:
``./stfufs -b 2001 -p 127.0.0.1:2000 -d 127.0.0.1:/usr usr``
Now client binds to port 2001, server is instructed to connect to 127.0.0.1:2000 (where proxy is configured to connect to 127.0.0.1:2001.)...
Not more on these (tricky) issues for now. In most cases the proxyless versions work fine.
Testing:
(Move this part to developer documentation)
There has been many bugs that has been squashed in this program after some testing. No-one can ever be sure that all bugs are gone, since there is no resources to do indefinite testing.
I've so far done some basic testing with devel/test.sh functions. Then I tarred ``usr/bin/``, which created 95M archive. ``tar -zdf`` verified
all ok. And, for heavy stfufs buffer runs, I've run ``while ls -l usr/bin; do :; done`` for some time..
More tests needs to be developed for more certainty everyhing works fine -- and for regression testing when new releases are made. I'll investigate in this (slowly, though); suggestions for tools/methods are greatly appreciated.
What's New in This Release:
· This release drops single element read/write caches and replaces them with a 1024-item offset table indexed by fd.
· It includes a separate server launcher which, if used, supports server versions using different communication protocols.

0 comments

Add to

 Del.icio.us   Digg It   Furl   YahooMyWeb   Blinklist

Simple TCP FUSE File System Version History

Related Software