Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A currently maintained fork of SSHFS

github.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: A currently maintained fork of SSHFS

#91

Post by aidenn0 »

blueflow wrote: post #80
aidenn0 wrote: post #76

Earlier quoted context omitted.

Not just rclone, but it seems that so many things are moving away from using the ssh_config; I have things setup to "just work" for so many hosts with OpenSSH, and having to individually configure a half-dozen programs that build on top of SSH is a pain. Sometimes it's because they use paramiko, other times it's because they want to pass their own configuration options to ssh that mess things up. Sometimes you can ma…

Can you name these programs? I want to add them to my 'painful' list.

I only use programs for which I've found a workaround due to the pain, so I can't list the ones that I don't have a workaround for. TBF two of the programs (emacs tramp and git-annex) I use regularly actually mostly respect ssh_config by default, but they override the ControlMaster by default (to do their own connection muxing) which requires me to do an extra authentication step.

Re: A currently maintained fork of SSHFS

#92

Post by ph4te »

FredFS456 wrote: post #75
jetbalsa wrote: post #65

Earlier quoted context omitted.

Wasabi might been a good choice for you on that front

Backblaze B2 is $5/TB/month, Hetzner is $4.08/TB/month for 1TB, Wasabi is $6.99/TB/month Wasabi seems like the most expensive here, with the caveat that Hetzner requires ordering discrete steps of storage rather than the 'pay-as-you-go' model of the other two

They are all OK to use, and each provider has pros and cons, depending on the use case.

Hetzner is the cheapest; however, your data is stored in Germany or Finland. They have free bandwidth, but you are limited to 10 connections at a time.

Backblaze B2 has 4 regions across the globe, storage is $5/mo, there is no minimun retention time, but does have a cost for API Calls(transactions), and in addition charges for egress data(downloads), so your $5/TB is a variable factor, and if you use your data, you may not achieve $5/TB, the cost will grow depending on the use case(there are free levels of transactions and egress)

Wasabi is $7/TB and has 13 regions across the globe, with free egress and no api charges. It does have 90-day minimum storage charge, which means you are billed for every object for 90 days regardless of if you delete it before 90 days. In addition, the free egress has limits to prevent system abuse. There is a 30-day deleted storage charge available if you purchase in bulk with their RCS(reserved capacity) storage plan. It's good if you want to store a lot of data that does not need deletion.

I have accounts with all 3 of these for different use cases.

Re: A currently maintained fork of SSHFS

#93

Post by crabbone »

unilynx wrote: post #72
crabbone wrote: post #44

Earlier quoted context omitted.

This is nothing extraordinary. I don't know why this is a tradition, but this is a very typical situation for C projects.

Compilation used to be slower, and one 5K line file would be noticeably faster than 10 500 line files, not to mention possibly having to build extra header files to connect them together. That would encourage larger files.

I could buy a similar argument for directories: you will almost never see a C project with sources in subdirectories of the top-level source directory -- this is because of the recursive Makefiles which earned quite a bit of a somewhat justifiable hate.

But I don't think compilation times explain the size of the source files. This hasn't been a problem for such a long time that I cannot even remember when it could have possibly been a problem.

I had seen the reverse problem, but not with C... rather with Python source files. The older parser used to be very bad and would start using too much memory if the source file was in the thousands of LOC. I had to witness this firsthand with SWIG-generated Python bindings. I don't remember this kind of problem with C compilers / other utilities though.

Re: A currently maintained fork of SSHFS

#94

Post by rofo1 »

Filligree wrote: post #49
nickcw wrote: post #36

Earlier quoted context omitted.

Interesting. I haven't tried a speed comparison but I know we sped up the sftp backend recently.

Does the FUSE mount work on OSX?

It does work, I use it regularly. However, it can hang the whole system in certain cases such as mount that went wrong, connection timeout between the servers (without -o reconect option on sshfs, but even with that sometimes).

Re: A currently maintained fork of SSHFS

#95

Post by tambourine_man »

duped wrote: post #74
Filligree wrote: post #49

Earlier quoted context omitted.

Does the FUSE mount work on OSX?

VFS on MacOS is a minefield. You either need to use a kext (bad option, for many reasons), a network file system (NFS or SMB) and pretend your VFS is a remote server, or create a FileProvider system extension (which cannot actually function as a VFS). If your workflow relies on a VFS that isn't NFS/SMB then don't use MacOS. fuse-t is kind of clever in that it spins up a TCP server that transpiles NFS requests into FU…

MacFUSE always seems unbearably slow to me. Specially in the Finder. Has it improved?

FUSE-T seems more future proof (no kext) and probably less likely to completely hang your Mac, but could potentially be even slower since it’s another abstraction layer in between.

It’s odd that there aren’t any great open source SFTP solutions for the Mac. CyberDuck and FileZilla are barely passable.

Re: A currently maintained fork of SSHFS

#96

Post by ics »

rsync wrote: post #52

A note … I have transitioned from years of macfuse + sshfs on Mac to just installing the excellent “mountain duck” tool which gives you finder and mount point access to an sftp endpoint. Very nice software and indispensable for me.

As a recently returned rsync.net customer, I was a bit surprised to peruse the docs and see that Fuse/sshfs is still up as a recommended option for Mac integration (see https://www.rsync.net/resources/howto/mac_sshfs.html). A few months ago this led me down the path of trying ExpanDrive/StrongSync, but this is the first I've heard of Mountain Duck (love Cyberduck though). I'm looking forward to giving it a spin now but if it has been working well for you please consider updating this page for others. Happy customer otherwise!

Re: A currently maintained fork of SSHFS

#97

Post by [deleted] »

FredFS456 wrote: post #75
jetbalsa wrote: post #65

Earlier quoted context omitted.

Wasabi might been a good choice for you on that front

Backblaze B2 is $5/TB/month, Hetzner is $4.08/TB/month for 1TB, Wasabi is $6.99/TB/month Wasabi seems like the most expensive here, with the caveat that Hetzner requires ordering discrete steps of storage rather than the 'pay-as-you-go' model of the other two

[deleted]

Re: A currently maintained fork of SSHFS

#98

Post by venatiodecorus »

dpatterbee wrote: post #48
Timshel wrote: post #11

Discovered that you can replace sshfs with rclone. And the project appear to be way more active : https://github.com/rclone/rclone Edit: cf: https://rclone.org/commands/rclone_mount/

I love rclone, I'm currently using `rclone mount` to mount a Backblaze B2 bucket to use as backing storage for Jellyfin and it works a treat. There are plenty of dials to tune things like cache size and duration to minimize unnecessary downloads from B2, and with my usage patterns it ends up astoundingly cost effective (although at some point I might move to Hetzner storage boxes for even cheaper storage).

this seems really expensive compared to a local nas, at least over the lifetime of your service. is there a reason you chose to go this route instead of local storage for media?

Re: A currently maintained fork of SSHFS

#100

Post by dpatterbee »

venatiodecorus wrote: post #98
dpatterbee wrote: post #48

Earlier quoted context omitted.

I love rclone, I'm currently using `rclone mount` to mount a Backblaze B2 bucket to use as backing storage for Jellyfin and it works a treat. There are plenty of dials to tune things like cache size and duration to minimize unnecessary downloads from B2, and with my usage patterns it ends up astoundingly cost effective (although at some point I might move to Hetzner storage boxes for even cheaper storage).

this seems really expensive compared to a local nas, at least over the lifetime of your service. is there a reason you chose to go this route instead of local storage for media?

A local nas requires much higher upfront costs, I would need space to put it, and it requires much more ongoing maintenance and whatnot. If you factor the cost of my time it probably doesn't really work out as cheaper.
Post reply on HN