Uploads and recently uploaded images (which are stored on f.imagehost.org) should be unaffected and continue to work as normal.

Update: the server OS was reinstalled, but it was the wrong version (as the server has loads of RAM, installing a 32-bit OS doesn’t make sense). Unfortunately this is going to delay things some further.

Update 2: Done! While there are still lots of little things (mostly cron jobs) left to set up, the server is hosting files again! Actually once the server came back online (hours ago) I had already hacked up a quick fix to have the other (working) server host the affected files, but this kind of overloaded that server a lot. I figured it was better to have the images load slowly than not at all. But from this moment on speeds should improve as the original server is now taking over the job again.

Update: unfortunately it looks like the system drive of the server will need to be replaced. This means even more down time unfortunately, as it’s going to take some time to get the OS reconfigured again after my provider reinstalls it. No data should be lost however as the drive isn’t completely gone (plus there are backups on other servers). In the mean while I’m going to try to get the main site back online first, using the server that is currently working.

Update 2: seems like when my provider mentioned a reinstall was necessary, they didn’t meant it needed to be done right away and that the system wasn’t booting – it is. So for a short while all of ImageHost.org should be online (pretty much) until the drive will be replaced in a few hours (after which a, b, c, d & g.imagehost.org will be temporary offline until the OS is reconfigured).

To combat this problem, I’ve put the new server I talked about in an earlier post (identifiable by the upload url e.imagehost.org) in to active duty immediately. The only problem is that the method my scripts use to transfer new uploads to this server (which unfortunately are still coming from the overloaded server) isn’t terribly reliable, so some uploads may fail. If that happens, just try again.

I apologize for the inconvinience. I have ideas on how these various issues can be addressed and handled better in the future, but unfortunately this will require further script development so it will probably not be ready soon enough to be of any help right now.

Update: above text applied to Friday, November 14. Site performance should now be back to normal.

Now eventually b.imagehost.org is also going to moved to the new server, but not until it has “cooled off” in a traffic sense (bandwidth usage peaked at 79 mbps yesterday) and new uploads are served from yet another new server (not yet ordered), as the new server already peaked at 35 mbps peak bandwidth usage. In total ImageHost.org consumed nearly 750 GB (gigabyte) in the past 24 hours, which would work out to over 20 TB (terabyte) in a month. That’s not something you’d want to burden a single server with, certainly not one that mostly serves relatively small files.

But anyway, my next task will be to get logparsing back online (but not the old inefficient way) as I got the feeling a good chunk of the 750 GB used in the past day was abused by files which used way more bandwidth than is fair.