As Linux-Mag points out (Gentoo Optimizations Benchmarked) using gcc optimizations for “omg, teh speed” is not all that practical. Sure, I’ll add some compiler flags here and there as long as I am compiling everything anyway but I don’t consider that a feature of Gentoo Linux.
I actually prefer Gentoo for the package management and customization via USE flags (even with the headaches that they cause sometimes). 
I had this genius idea about using sshfs with rtorrent. I thought that this use case would fit best in situations where you have good bandwidth but not much diskspace, such as my linode VPS (review). So, I’ll attempt to share my findings in this regard.
If you are not familiar with rtorrent. You just need to know that it is a powerful, lightweight bittorrent client. It has a “watch” feature that watches a directory for new torrents, and obviously it can put downloaded files in a specified location. I tried both of these with sshfs.
First, I was having trouble with rtorrent just ‘freezing’ up when I put a torrent file in the sshfs accessible watch dir. I didn’t quite know what was wrong here. Research led me to rtorrent bug 322 and that sshfs did not support filesystems without mmap properly. Darn. More research led me to a recent kernel commit that looked promising. Low and behold, reboot my host with 2.6.31.x kernel and rtorrent works with sshfs watch and destination directory. Yay.
Well, not so fast…
The performance is quite poor with the destination directory on sshfs. This is to be expected because now your download speed for torrents is limited to the download speed of your final destination. But, rtorrent was only giving me a sustained speed of 1/4 of that demonstrated with a simple file copy to the destination. I speculate that this is from the rtorrent overhead or maybe fragmenting? Not sure exactly and I don’t care. My solution to this was to use the rtorrent “move on finished” feature that downloads the file to local disk and then moves it to sshfs destination after it is finished. Amazingly, this works quite well.
My testing scenario was the following:
-79MB Gentoo 2008.0 install cd torrent. With the complete sshfs solution, it took ~6 minutes to download (to the sshfs destination) and then 5 minutes to check the hash. So, roundtrip of 11 minutes from start download to seeding. With the on_finished solution, it took 1 minute to download (to local disk) and 1 minute to check the hash and move to the sshfs destination. For a roundtrip of ~2 minutes from start of download to seeding.
In conclusion, this isn’t the perfect solution because you impose a large bottleneck into the mix and unintended I/O activity on the local disk. However, it works for me and what I am doing. Maybe it will give someone else some ideas in the future.
I recently had a bit of downtime on my linode. If you are wondering what a ‘linode‘ is, check out my review or the website. And a big thank you to the folks that used my referral code when they got setup with linode themselves, you guys rock!
So, about my recent 1/2 day downtime. It was self-inflicted because I wanted to move to a different datacenter. I moved my linode from Newark, NJ to Dallas, TX. It is quite a long story, but it boils down to a problem with my ISP (Comcast). I was only able to pull 100K/s from the Newark datacenter and 2-3M/s from the others. This was unacceptable. I tried to get it escalated past Comcast’s frontline support but they kept asking me questions like “Do you use a router? If so, each computer only gets 1/2 the speed” & “Every computer is different. I’m glad that you can get 3M/s from another host, that is really good” Sigh.
At least Linode’s customer server was helpful and allowed me to work around the
So, to finish the story off. Linode++, Comcast–. I wish I didn’t need to do something like this, I wish my ISP was…I don’t know…smart?
About