-
Notifications
You must be signed in to change notification settings - Fork 0
SSHFS
See https://github.com/macfuse/macfuse/wiki/File-Systems-%E2%80%90-SSHFS
1. I am using SSHFS and changed a file "externally" (not through sshfs/"FUSE for OS X") on the server, but in the SSHFS volume, I am not seeing the changes. In fact, when I copy the file through SSHFS, I get the old content, etc.
"FUSE for OS X" itself is not a distributed remote file system! It is a mechanism for building arbitrary file systems. If you change things "externally" to "FUSE for OS X" (like, a file on the remote server in the case of SSHFS), in general, things need to be done proactively to tell "FUSE for OS X" that something has changed, otherwise you will get such "incorrect" behavior. In particular, SSHFS is not meant to replace things such as NFS, AFP, and SMB - it is meant to be a substitute when you do not have any remote file sharing access to a computer, but you do have SFTP access. When you use SSHFS, from the server's standpoint, you are just accessing it using SFTP. It is not as if the server is going to notify an SSHFS client of modifications by other clients.
To make SSHFS (or any other file system) "catch up" better with "remote" changes, there are a few things you can do. You can use the -o auto_cache
option. This would make "FUSE for OS X" purge a file's in-kernel buffer cache if a change in the file's size or modification time is detected.
A worse way to have this mode of operation (where you can change things remotely at any time) is to disable caching in SSHFS (look at the various -o cache
options in SSHFS, in particular, -o cache=no
). Then, additionally, you need to tell "FUSE for OS X" not to cache things on its end, too. You can use the -o nolocalcaches
option, which turns off readaheads, the unified buffer cache, and the pathname resolution cache (all in the kernel). At the cost of some overhead, which could be substantial in certain cases, this will give you the behavior where most requests will have to go to the server and will therefore have more up-to-date information. Note that auto_cache
is vastly preferred over this approach.
An example command line for this mode of operation could look like the following:
sshfs user@host:/dir /tmp/ssh -ocache=no -onolocalcaches -ovolname=ssh
If you are developing a "FUSE for OS X" file system and you want to handle such scenarios better within your file system, you should consider mounting your file system with the auto_cache
option. You also have the option of using the fuse_purge_np()
library function directly, although it is likely to be overkill.
2. SSHFS is not reporting the correct "disk space" for the remote "volume"? It seems to have 1,07 TB (1000 GiB) or some such number hardcoded.
Yes, indeed. Remember that there really is not an SSHFS "volume" per se: SSHFS just uses SFTP to provide an apparently local view of a remote directory. SFTP does not give you disk usage or availability for such a remote directory, so SSHFS does not really have a choice but to cook up some value.