So long again, Linode
I came back to Linode because although it was painful to squeeze my server into a Linode 768, it was even more painful to deal with the crappy service of ServerPronto. If there is one sure thing in the VPS hosting world, it's that Linode's service and system management services are head and shoulders above everyone else.
However, I have been continually and constantly disappointed in the disk space offerings of Linode. My particular workload for my server is very low CPU and fairly low bandwidth, but more demanding of disk space. This is because I used my server for primarily two things: email for my family, and our online photo album.
Every year or so my server would creep up to about 95% disk capacity and I would have to go in and prune stuff out, sometimes useless stuff that I didn't need to be burning disk space on, but sometimes more important stuff (like the backup of important documents from my home computer which I stopped storing on my Linode because I couldn't afford the disk space).
The unfortunate thing is that Linode doesn't offer disk space upgrades at anything approaching a reasonable cost. To add 10 GB of storage would be $20 per month, which is astronomically expensive. So I've been forced to once again look elsewhere for hosting.
I learned about Amazon EC2 "micro" instances and because of the low-CPU, high-disk usage nature of my server, it's a good alternative to Linode for me. For approximately half the cost of a Linode I get about twice the disk space, and I can add extra disk space at ten cents per gigabyte per month, which will allow my gallery site to expand by its yearly amount without ever hitting a storage ceiling.
I have already transferred my Linode server over to an EC2 micro instance - after alot of struggling, I finally figured out a method that worked for me, which was to create a micro EC2 instance using the standard Amazon AMI, then shut it down, start up another AMI, mount the virtual disk of the first AMI in it, and rsync my Linode's entire filesystem over top of it. Then I took the /boot and /etc/fstab from the running AMI and replaced the rsync'd-over filesystem's versions with those, and viola, I was able to reboot the EC2 instance with exactly the same filesystem as my Linode had, so once I switched DNS over it was is if I was running exactly the same server. I had also tried starting up a new EC2 instance and just transferring my data over, but I ran into alot of problems with gallery - this software is some of the most contentious I have ever run into when it comes to upgrading to a new version. Turns out that to go from gallery2 to gallery3 would require switching database backends because postgresql is no longer supported. And I ran into tons of problems trying to upgrade my postgresql database to the updated version that came with my new EC2 instance. In short, it was much more difficult to upgrade to newer server software than it was to just continue to use my existing outdated software, so rsyncing over my Linode's filesystem onto an EC2 instance turned out to be a much more straightforward and easier option.
Now EC2 micro instances are not perfect; they have two considerable disadvantages when compared to a Linode: one, they are CPU throttled in a very braindead and annoying way; which is to say, that they will allow processes in your virtual server to 'burst' to more than the standard CPU allotment, but then after about 15 seconds the EC2 instance gets throttled hard, to the point of complete unresponsiveness. I'd much rather that they simply did not allow my micro EC2 instance to burst at all, because I'd rather just have a more limited CPU that never became completely unresponsive when being throttled. This will rarely be an issue for my server because it is so low CPU utilization, but I have noticed that if I, for example, try to build software on the server, it will enter into the dreaded burst-throttle-burst-throttle cycle; and also when photos are resized on upload to my gallery, the same thing sometimes happens.
The second major disadvantage of EC2 compared to Linode is that the 'control panel' for EC2, and the general process of setting up and managing instances and volumes, is not nearly as seamless as it is for Linode. Amazon provides API access to all of this functionality but their own web front end access to this API is very lacking; and furthermore, the tools that are available that implement the Amazon API are fairly crappy as well. There may be third party solutions that are better, but just using the standard Amazon tools is an exercise in frustration. Many of them are Java based and inexplicably hammer the CPU, to the point of also causing throttling on a micro EC2 instance just when doing something as simple as querying for the set of volumes that are allocated to an instance.
All that being said, cost is a major point in favor of EC2; the micro instance with all costs included is about half as expensive as a Linode 768 while providing about 2x the disk space and with the option of cheaply adding disk at ten cents per GB per month.
And for this reason, I'm sorry to say that it's time for me to say goodbye to Linode again. If Linode could just offer disk at anything approaching a reasonable price, I'd never have left, and unless this changes, I won't be coming back; but if Linode can somehow become competitive on disk space, then who knows, I might be back again as I was before.
Goodbye Linode, and thanks for the great service and performance over these years!
38 Replies
You post makes it seems like Linode has let you down somehow, but since 2008, Linode has made several substantial increases in the resources available to each plan, without increasing the price of that plan (including a 33% disk space increase).
Seems like an awful lot of whining about an "issue" you knew about when you signed up.
@chesty:
I didn't think it was whining at all. It was feedback, which I'm sure linode appreciates. Companies pay for feedback, linode is getting it here for free.
Thanks for defending my post, it is sincerely appreciated.
If you have been reading these forums for years then you will be aware that I have provided lots of "feedback" on this issue, and some of it does border on whining, unfortunately. It is frustrating to have a service that is so close to ideal but that I can't use because of one drawback (expensive disk space).
That being said, I didn't think I was whining in this post as much as just giving out information and also putting Linode on notice a little bit with regards to needing to provide more reasonable disk space prices to avoid losing other customers.
If you want storage you use something slower, the largest 7200RPM drive is 3TB so you can see why amazon with it's s3 storage is cheaper.
I'll happily pay for the faster disks at reduced storage, if I want space I'll dump my files on s3.
@JshWright:
Why did you "come back" at all?
Already answered in my post.
> You post makes it seems like Linode has let you down somehow, but since 2008, Linode has made several substantial increases in the resources available to each plan, without increasing the price of that plan (including a 33% disk space increase).
Linodes resource increases are really awesome; but the disk space started out overpriced in 2003 and this has not substantially improved; in fact I think they've become relatively more overpriced over the years, to the point where now they're 20x more expensive than competitors.
I feel in some ways that Linode did let me down; I joined in 2003 hoping that when Linode scaled up, as it has done over the years, that the disk space prices would go down. But they haven't, at least not at a fast enough rate to come into a reasonable price range. Linode absolutely delivered 100% on all service promises made though; it's just that my hopes for reduced disk costs were never met.
> Seems like an awful lot of whining about an "issue" you knew about when you signed up.
There were never better alternatives for me (I did try, with ServerPronto), but now with EC2 micro, there is a credible alternative.
I'd like to repeat that Linode is absolutely superior to every other VPS service as long as your workload fits within the Linode resources. So I don't expect anyone whose server fits within Linode's provided space to even consider moving elsewhere, as for basic hosting Linode just can't be beat.
@obs:
Linode isn't suited for storing large amounts of data, no decent server is, why? Well most people want servers to respond quickly to do that they need fast hard drives, so far as I know the biggest 15k rpm hard drive is 600GB.
If you want storage you use something slower, the largest 7200RPM drive is 3TB so you can see why amazon with it's s3 storage is cheaper.
Amazon's EBS storage is as fast as a local hard disk from my research. And it's 10 cents per GB.
> I'll happily pay for the faster disks at reduced storage, if I want space I'll dump my files on s3.
This sentence is self-contradictory, because I think you're leaving out details. A remote S3 connection would be slower than any local hard disk, so it would be disqualified by your "faster disks at reduced storage" statement. I think that what you're saying is that your workload has a small data set that you'd like to have fast access to, and a large data set that can have access so slow that a roundtrip to S3 is acceptable.
For those who want a large amount of reasonably fast space though, Linode is not well suited. I could have looked into options for offloading data to S3 (it's my understanding that with gallery2 there are plugins that will let you store your photos and movies on S3), but this would have probably required many hours of reconfiguring to get working for me, and at that point, I figured why not just spend the time switching over to a hosting solution that doesn't require jumping through those kinds of hoops?
I have 23Gb stored at amazon s3 and use around 10gb on linode, works perfectly fine for me.
If you host your server on amazon ec2 then you can access s3 via their private network inside the data centre which will make it appear faster for you, however if you do bench marks you will find that ec2 disk io is slower
Here's some good benchmarks
If I was doing what you're doing I'd use amazon, it's ideal for serving large amounts of data, I'd not dream of hosting something I need to access quickly i.e. a relational database.
Linode simply isn't designed for what you want, it's designed for speed.
@obs:
You need to research better, amazon s3 can be linked to directly so you don't have to use it as a remote disk many sites use it as a cdn.
I might not be understanding what you are saying, but I already alluded to setting up my gallery software to serve the photos/movies off of S3 (linking to them rather than serving them locally). But I concluded that rather than playing that game, it would be easier and cheaper to just directly use EC2.
> Linode simply isn't designed for what you want, it's designed for speed.
I think that EC2 is definitely designed less for speed and more for scalability; an EC2 micro instance doesn't even have the pale shadow of the CPU performance of the lowest end Linode.
When I first joined Linode in 2003 it wasn't clear that the focus was going to be speed, or that cheap disk space would be contradictory to that purpose, or that Linode wouldn't be able to offer both fast local disks and big network storage, but all these facts are pretty clear now.
@bji:
This is because I used my server for primarily two things: email for my family, and our online photo album.
I've never really understood why you'd want to use a Linode for the above two functions when they're available in the cloud for much cheaper. Personally, I use Google's Gmail for email and PicasaWeb for online photo's and albums. It runs me $5/year for 20GB of storage and stores all my digital photos I've taken since 2000 in 1600x1200. You can use higher res if you want. If you need more storage, choose the 80GB option for $20/year or the 1TB option for $256/year. Ditto for email and email domain hosting (and you get 7GB for free, no matter if you use gmail.com or your own domain).
A quick search shows there are plenty of other sites that offer the exact same features for more or less the same price.
I have a Linode, but I don't use it for online storage - it's not what it was intended for (at least, in my book).
–deckert
Thanks,
@Deckert:
@bji:This is because I used my server for primarily two things: email for my family, and our online photo album.
I've never really understood why you'd want to use a Linode for the above two functions when they're available in the cloud for much cheaper. Personally, I use Google's Gmail for email and PicasaWeb for online photo's and albums. It runs me $5/year for 20GB of storage and stores all my digital photos I've taken since 2000 in 1600x1200. You can use higher res if you want. If you need more storage, choose the 80GB option for $20/year or the 1TB option for $256/year. Ditto for email and email domain hosting (and you get 7GB for free, no matter if you use gmail.com or your own domain).
A quick search shows there are plenty of other sites that offer the exact same features for more or less the same price.
I have a Linode, but I don't use it for online storage - it's not what it was intended for (at least, in my book).
–deckert
I have been running my own email server since 1998 when it was a better option for many reasons than online mail services (gmail didn't even exist). It was mostly through inertia and concerns about not 'owning' my email that I didn't move to an email provider.
Well, along with switching to EC2 I have also offloaded my email to gmail; I use pobox.com as a forwarder for my domain's email to gmail and to my 'users' (i.e. my family) the transition was seamless as they still have their same email addresses and I just changed their thunderbird config to use gmail's IMAP instead of my server (and I also IMAP transferred over all of their old mail to gmail so it was really totally seamless for them). Honestly I don't know why I didn't do this sooner because it's so much easier than managing my own server. Professionally managed ant-spam is worth the cost of admission alone.
As to my photo gallery, my wife and I are kind of adamant about owning it; we are hesitant to put our album in the hands of a third party that may go under and take with it all of our hard work on the album. So I run my own gallery software and will continue to do so, and for this reason, I need tens of GB of disk space and unfortunately Linode is just not ideal for this type of server.
As I think about it more, it might have been even better for me to have switched down to a Linode 512 and take the time to move my gallery over to S3 hosted photos, so that my disk space requirements would be minimal and I would still get all of the benefits of Linode. A Linode 512 is only about $5 more expensive per month than an EC2 micro instance and although the Linode has about 1/4 the disk space for that price, just about every other aspect is heavily in Linode's favor.
But, since I've already done it, I'll stick to this EC2 instance for the yearly term that I have signed up for and maybe come back to Linode next year.
@bji:
As to my photo gallery, my wife and I are kind of adamant about owning it; we are hesitant to put our album in the hands of a third party that may go under and take with it all of our hard work on the album.
So naturally you put your valuable photos up on the cloud???
The same cloud that the press has had a field day in detailing how they roll over for the feds. The same datacenters where the feds are hauling out unrelated servers by the truck load on one warrant?
The only way you will OWN your photos is if you store them on a box that you own, in your own house, preferably buried somewhere in your backyard and connected by untraceable power and data.
Even then, nothing is 100% safe. You MUST of course have backups right? So in the end, what difference does it make who hosts your files? And once they're on the net anywhere, you have to worry about unlicensed use - so you best watermark every photo.
Stuff is either shared or private - you really can't have it both ways.
@vonskippy:
@bji:As to my photo gallery, my wife and I are kind of adamant about owning it; we are hesitant to put our album in the hands of a third party that may go under and take with it all of our hard work on the album.
So naturally you put your valuable photos up on the cloud???The same cloud that the press has had a field day in detailing how they roll over for the feds. The same datacenters where the feds are hauling out unrelated servers by the truck load on one warrant?
The only way you will OWN your photos is if you store them on a box that you own, in your own house, preferably buried somewhere in your backyard and connected by untraceable power and data.
Even then, nothing is 100% safe. You MUST of course have backups right? So in the end, what difference does it make who hosts your files? And once they're on the net anywhere, you have to worry about unlicensed use - so you best watermark every photo.
Stuff is either shared or private - you really can't have it both ways.
I don't care about unlicensed use. I care about the time spent setting up the photo gallery, uploading photos, adding comments, collecting comments from family, etc, and all that being lost if the album hosting went down.
And yes, I have nightly backups of the photo albums (and all other files on my server) to my home system, something which I cannot do with a hosted photo site like Picasa (or can I? I never researched that option, but I don't know how they would allow you to do a full backup of all aspects of your Picasa albums to your home system (including comments, layout, etc) or in what format the backup would be in if they let you do it).
Also the rollover for the feds comment, and the burying servers in the backyard, etc, is tinfoil hat stuff. I'm practical enough to realize that the only real danger to my data is if the hoster went out of business or if their data center blew up, neither of which is particularly likely, but just likely enough that I don't want to trust my albums to a third party that does not allow me to backup every aspect of the albums like I can do with my own hosted gallery.
> By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services.
> You agree that this license includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.
@BarkerJr:
This is why I don't want to use PicasaWeb:
> By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services.> You agree that this license includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.
Wow that's pretty chilling. Although, I have to wonder if what they're getting at is trying to put a disclaimer up so that they can't be sued for copyright infringement for displaying your photos no matter what form they choose to display them (like, if they change their Picasa web hosting to automatically resize images as a feature or something in a way that changes the size of the images that you uploaded in the past, they don't want you to sue them for altering your copyrighted images).
One could interpret their legalese as essentially protecting them from every kind of frivolous copyright infringement lawsuit that someone hosting copyrighted content on their site could bring, and not as a means to give themselves the ability to 'steal' your content for their own use.
Of course, the effect of the legalese is the same in either case, whatever their intention: they essentially own any content you upload to their site. I guess each individual would have to decide if they are OK with that; and although I am not particularly paranoid, I wouldn't be comfortable with that arrangement.
I want to make clear again that my post, and this thread, is not about bashing Linode as being worse than a micro EC2 instance; I think that probably everyone here on Linode already realizes how incredible this service is. If your content fits in a Linode, then there is no reason to switch to another hoster (aside from some of the more esoteric features of EC2, which wouldn't be applicable to alot of people). I did want to let Linode know that after years of complaining about the cost of disk space, I eventually did put my money where my mouth is and leave because of it; only in the hope that maybe this will make them think about making lower cost disk space available to Linodes so that I can eventually come back.
I appreciate that your post was at the very least constructive, as opposed to, "So long b*tches!!!!1111".
Hope this doesn't go unnoticed. It is a shame you signed up for a year with EC2 though. Best of luck.
I turned off commenting on my gallery (which nobody was really using anyway) which will help, but in the end the only way to keep my EC2 instance from blowing up was to run a program called 'cpulimit' to limit my HTTP processes to 20% CPU each (with 3 processes and a maximum 60% CPU utilization).
I tried to ask Amazon if they'd consider a feature request of allowing customers to opt out of the 'burst' feature of micro instances, so that the instance would get a guaranteed constant amount of CPU instead of burst-throttle-burst-throttle, but of course they never even acknowledged my suggestion.
I am not sure why I never noticed the spambots on Linode, either Linode's instances are so fast that I never even noticed the load, or the EC2 IP block is more high profile and more inviting to spambots; or maybe it's just coincidence.
I'm already regretting my move to EC2 micro instance. Of course I need the disk space so I'm kind of stuck between a rock and a hard place now …
If the micro instance was able to burst to the full capacity of the machine for extended periods then they'd probably get users spawning a bunch of cheaper micro instances instead of the larger instances. You'd get customers with CPU intensive workloads downgrading their existing instances.
S3 or some other storage service along with a Linode probably would've been a better option.
@-Alex-:
I'm guessing that Amazon will intentionally keep the micro instance throttled to ensure that you aren't getting too much CPU usage for free.
If the micro instance was able to burst to the full capacity of the machine for extended periods then they'd probably get users spawning a bunch of cheaper micro instances instead of the larger instances. You'd get customers with CPU intensive workloads downgrading their existing instances.
S3 or some other storage service along with a Linode probably would've been a better option.
You don't understand. I don't mind the non-bursted, guaranteed CPU capacity that Amazon provides with the Micro instance. It's not blazing fast but it's OK. The problem is that they allow a burst, and unless you have some way of limiting programs from taking as much CPU as is available (i.e. artificially putting 'sleeps' in programs like cpulimit does), the EC2 micro will burst to more than the allocated CPU cycles.
After about 10 seconds of burst, Amazon has some kind of CPU rate limiter in place for its instances that kicks in and throttles the instance HARD. Like, to the point of taking away 90+% (feels more like 99%) of CPU. This is the problem that I have. I don't mind the burst, but the throttle is ridiculous. So if I can only have both or neither, I'll gladly take neither. If Amazon wants to slice the CPU up so that my micro instance has a guaranteed "reasonable fraction" of the CPU, then that's fine. But allowing my instance to burst when I don't really want it to, and then throttling my instance to near unusability, is a terrible policy.
I also used to whine about the lack of disk space, but nowadays I just buy a cheap VPS or a backup service with lots of disk space (100GB for $14.99, etc.) preferably in the vicinity of a Linode datacenter. I store pictures and other large stuff in the other account, and mount it on my Linode using NFS over an encrypted tunnel or SSHFS. That way, I get a large and relatively low-latency disk attached to my Linode for only a few more dollars a month.
It's much faster and more convenient than S3, especially with existing apps that can't be easily adapted to use S3. The webapp won't even know where the files are actually stored.
@hybinet:
but nowadays I just buy a cheap VPS or a backup service with lots of disk space (100GB for $14.99, etc.) preferably in the vicinity of a Linode datacenter. I store pictures and other large stuff in the other account, and mount it on my Linode using NFS over an encrypted tunnel or SSHFS.
That would make a pretty nice HOWTO for the library.
@vonskippy:
@hybinet:but nowadays I just buy a cheap VPS or a backup service with lots of disk space (100GB for $14.99, etc.) preferably in the vicinity of a Linode datacenter. I store pictures and other large stuff in the other account, and mount it on my Linode using NFS over an encrypted tunnel or SSHFS.
That would make a pretty nice HOWTO for the library.
Maybe. But it would be somewhat inappropriate to endorse purchasing services from other VPS companies in a Linode Library article. Also, the reliability of this setup depends entirely on the quality of the "cheap VPS" which, since it's cheap, is unlikely to be up to par with Linode.
Anyway, here's a quick overview:
sshfs username@remote.ip.addr.ess:/remote/directory /local/mountpoint
For a personal or family gallery, a backup/storage account with BQBackup, WebbyCart, etc. is probably all you need. They give you SSH access, so you can add a no-password public key to your account and use SSHFS to mount your backup directory. SSHFS tends to perform badly, but it's OK for small sites. The backup/storage service provider might become unhappy, though, if you move a lot of data all the time.
For more intensive use, you'll probably need a real VPS on the other side. I won't list specific companies here, as they're Linode's competitors. The cost per GB tends to be higher with VPSs than with backup/storage services, so expect to pay more. Whether or not you can use NFS (which is faster than SSHFS) depends on what the VPS host allows. OpenVZ hosts aren't as flexible with kernels as Xen hosts are. Cheap VPS hosts also tend to be somewhat less reliable than backup/storage services, even at similar prices per GB. (Backup/storage services don't need to invest as much in CPU and RAM.)
Whatever service you use, latency is the most important thing to consider. Remote filesystem access generates a lot of back-and-forth traffic, and even a latency of 30-40ms can drastically kill your filesystem performance. Never go for a server more than 10ms away from your Linode. And always remember you're burning up your bandwidth every time you access a remote filesystem.
The best option, of course, would be for Linode to provide cheap extra storage that can be accessed over the private network. Since it seems Linode is not willing to take that route, the second best option would be for someone to launch a storage service in some of the same datacenters that Linode uses. Perhaps they can cut a deal with Linode so that their services can be accessed over the private network.
@mnordhoff:
In this case, an advantage of S3 and similar services is that they can directly serve the files over HTTP, so you can include the S3 URLs in your web pages instead of proxying it through your Linode, and latency is only an issue for the initial upload.
That can also be a serious disadvantage, depending on what you're trying to do. If you want to put your files behind a login, payment gateway, or some other form of access control, you'll probably need to proxy all of that stuff through your Linode anyway. You could, of course, use S3 with tokens that expire after a while, but that's probably going to require serious modifications to whatever app you're using. The OP clearly stated that he doesn't want to customize his gallery app.
Also, it's possible to serve your public files directly from any other server, if you follow the two-VPS trick that I described above. There's no difference between S3 and my two-VPS trick in that regard, and sometimes S3 costs more per GB.
@hybinet:
The OP clearly stated that he doesn't want to customize his gallery app.
Well I'm doing that as we speak. The last thing I'm going to be doing with this crummy EC2 micro instance is taking advantange of its location within the Amazon network to copy all of my gallery images/movies into an S3 bucket. Actually I have the copy operation currently underway and am watching it in a terminal window …
Look for me pretty shortly to be writing a "Hello again, Linode!" thread as this EC2 micro experiment has ended miserably.
@hybinet:
bji coming back to Linode in 3, 2, 1…
I also used to whine about the lack of disk space, but nowadays I just buy a cheap VPS or a backup service with lots of disk space (100GB for $14.99, etc.) preferably in the vicinity of a Linode datacenter. I store pictures and other large stuff in the other account, and mount it on my Linode using NFS over an encrypted tunnel or SSHFS. That way, I get a large and relatively low-latency disk attached to my Linode for only a few more dollars a month.
It's much faster and more convenient than S3, especially with existing apps that can't be easily adapted to use S3. The webapp won't even know where the files are actually stored.
As expected, s3fs SUCKS and trying to use it to extend the storage of my Linode for my photo gallery just isn't working very well (aside from s3fs generally being unreliable and wonky, it also has the unfortunate behavior of fetching the entire file any time any part of it is asked for, and this interacts badly with the gallery software).
Can you give some more details on your method of remote disk storage? What vendor have you found cheap and reliable for this purpose? Have you tried SSHFS (which seems easier to set up than NFS), and can you compare it to NFS for this purpose?
@bji:
Can you give some more details on your method of remote disk storage? What vendor have you found cheap and reliable for this purpose? Have you tried SSHFS (which seems easier to set up than NFS), and can you compare it to NFS for this purpose?
@Guspaz:sshfs is like s3fs in that it's a kind of hacky kludge that works OK for casual stuff, but not for serious stuff. It's really easy to use and set up, but it completely falls apart under any load, so it should be used for convenience, not as a replacement for SMB of NFS.
In my experience, sshfs has been much more reliable than s3fs. The code base is rock solid, and the performance is way better than s3fs. This probably has to do with the fact that SFTP, the underlying protocol for sshfs, was designed for filesystem-like access patterns. If I remember correctly, with SFTP/sshfs you don't have to transfer the whole file to access a few bytes or the metadata. S3 on the other hand is based on a RESTful protocol, which sucks for a filesystem.
However, as @Guspaz said, sshfs is nowhere near as robust as NFS or CIFS (Samba). Read-only access is generally OK as long as the latency is low, but try writing to the same file at the same time and the contention will get ridiculous. For example, it's possible to run a read-write SQLite database over NFS, but you don't want to do it on an sshfs volume.
It's probably OK if all you're doing is fetching old photos and sending them over the web once in a while. I'd run forum archives on an sshfs volume for months without a problem. Generating a few thumbnails might also be OK, depending on the latency and bandwidth between the hosts. But anything more and you should be looking at NFS or a local filesystem.
I don't know how Gallery organizes uploaded files, but if it's anything like /year/month/filename, it'll be very easy to transfer old photos to a remote server and keep newer photos locally, without changing any PHP code. Just mount the remote volume somewhere outside of the docroot, move old directories to the remote volume, and replace their original locations with symlinks. Do this every now and then as your local filesystem gets filled up. Gallery won't know anything is amiss. (In case it's pesky enough to complain about a symlink, just do a "mount –bind" instead.)
The primary benefit of SSHFS, of course, is that it works everywhere. Even the cheapest backup service or large-disk VPS host supports SSH. I know several reliable hosts, but since some of them are Linode's competitors, I won't post their names here. I'll PM you.
Some magic could be thrown into the web server to redirect requests for relocated content to S3. That would cut down on the download-then-transmit tromboning and gallery2 hacking, at the expense of another brief HTTP request.
what about linking assets to other storage-only services like dropbox, spideroak or ubuntuone? You can get 100gb for $10-$20. It won't be the fastest but you can't have it all.
Automate your Linode Apache so bigger file types are automatically fetched remotely, maybe add a cache on your node. Makes sense?
IMHO asking for speed + storage + cheap is asking for trouble. Cost-benefit looks ugly once you include your own wasted time.
– p
Dropbox will disable access to a file if it gets more than 10 GB/day of traffic if you have a free account, and 250GB/day if you have a paid account, but since you're not supposed to use it for web hosting like this, I'm not sure how they'd react.
People have come up with some very creative uses for DropBox and though they're not officially sanctioned they've been there for a while.
SpiderOak would be in a tough spot to accuse you of specifics without admitting their "zero-knowledge" encryption is fluff… and lose their #1 differentiator over DropBox.
Anyway I came across this thread cause it's the first I saw when I joined the forums. It makes for interesting debate about possible architectures but with all due respect it's a lot of noise for stated goals that make little sense.
I can't image why you'd want to go through a web host for family photos unless you have many different personas (serial liar husband, Mormon, Muslim whose wives didn't get the memo?). Considering how few users would access the family photo album just buy the extra Linode space if it's all that important, otherwise set up a DMZed Synology at home. Definitely don't mention "'privacy" if Google, Yahoo or Amazon are part of the chain; they're doormats.
My point is that I don't enjoy getting ripped off but neither do I want the host I rely on to go under or go Mr Hyde because of the current retarded pricing race to the bottom. Anyone who's whining over pennies obviously never ran a business; what can you expect from 4$/mo plans other than -- at best -- a $4 monthly turd?
I don't want my host to "barely make it", to get bear-hug acquired like MySQL, OpenOffice, etc., -- I'll pay a fair price so they can grow and their products and service keep getting better.
I'm coming from WestHost which used to be an awesome boutique shop with great support, root access & gcc but turned into a pumpkin after they got acquired, a godaddy wannabe, which I doubt ranks very high among Linoders.
I'd blow my brains out if I computed how much time I wasted during that period.
-- p