Case in point: An rtorrent slave setup

Edit: Unfortunately, the images originally included in this post are gone, because of hosting problems in late 2009. My apologies.

With two wounded laptops lying around the house, and no real prospects for fixing either one of them in the near future, I decided it was time to take my own advice, and I’ve set up the battered Thinkpad as a torrent slave for my Inspiron. I suggested this setup about a year ago (as well as some other ideas), when I described a cool way to set up rtorrent, and since I have the system working and in place now, I thought I would share the nitty-gritty.

I built this with both machines running Arch, mostly for ease and speed of setup. Ubuntu and Crux will both work just as well, but for my own case I wanted to be able to build and install stuff as quickly as possible, so Arch was ideal for me. (Let’s face it, pacman makes aptitude look ridiculously slow. 😈 )

I’ll explain the situation, since it is pertinent: The main laptop, the Inspiron, has a 120Gb modular drive that I use to hold files, packages, software, notes, and so forth. The main drive in the Inspiron is a faster, but smaller 60Gb drive that serves as a system drive and standard /home directory. With that arrangement, I can dump files into the modular drive when I feel I need to save them, and not worry about system rebuilds or drive crashes. I’m free to play around.

The Thinkpad has a single drive in it, and it’s neither fast nor big — a lousy 4200rpm 20Gb IBM-DJSA-220. Regardless, all of the files I download need to be shifted back to the Inspiron when they’re done.

For that reason, I actually have two shared directories listed in the client’s /etc/fstab — the download directory on my Inspiron system drive, and a temporary directory on the modular drive. When a torrent file is downloaded it is dropped in the download directory, but when the Thinkpad saves information, it sends it back across the network to the modular drive.

The Thinkpad uses its own $HOME/download directory as a session directory, and that’s what’s defined in .rtorrent.rc. The Inspiron’s download directory is mounted to $HOME/watch on the Thinkpad, and that’s how it knows what torrents are in queue.

NFS handles the transfers, of course. Both machines are wired directly into my proprietary router, and there is no access to the wireless system. I did that on purpose; I don’t care to share any of my drives with the local populace (which would probably be unlikely anyway, but that’s beside the point). 😉

These aren’t much in the way of screenshots, but hopefully they’ll give you an idea of the arrangement. Here’s the host machine, the Inspiron, with the torrent in the download directory and the target file stashed on the modular drive.

Of course, the size of that file is reported as if it had already been downloaded in full; it has, in fact, only been downloading a few minutes, as this screenshot from the client machine, the Thinkpad, shows.

The lower half of the screen is shattered, which is why I don’t have anything there. There’s nothing installed on the client aside from X, Openbox, Sakura, rtorrent, elinks and few other maintenance programs. There’s not much point in installing a whole lot on this machine, since I can’t see what most of it does.

Here’s the sessions folder — the $HOME/downloads folder on the client. You can see the temporary files here that rtorrent creates.

On the left side is the symbolic link to the modular drive on the opposite machine, plus the $HOME/watch folder, which is ratcheted to the $HOME/downloads folder on the Inspiron. The contents of $HOME/watch are the same as $HOME/downloads in the first screenshot.

And that’s about all it takes. As soon as a *.torrent file appears in the watch directory, rtorrent starts working on it, sending periodic bursts to the modular drive on the host machine. Memory caching takes the brunt of the read-writes as far as I can tell, so there’s not a continual stream of traffic between the two computers, as you might expect.

You could change that if you want. I originally set up the Thinkpad with all the action isolated on that one machine, but I decided I would rather have them run in syncopation. If you prefer you can move files manually to their destination; I have a hard time seeing what is going on, so I prefer to have the file automagically transferred. The downside is that both machines need to be working to complete the arrangement. (It’s also worth noting that I can download a torrent on the client machine, add it to rtorrent manually, and the file is automatically sent to the modular drive.)

Any questions? Of course there are. Here are the configuration files for /etc/exports on the host, and /etc/fstab and .rtorrent.rc on the client. Setting up your network and NFS on each machine is your responsibility. For ease of use, I strongly recommend taking a look at the Arch Linux wiki page on NFS, which has never let me down. 😉

Host: /etc/exports

# /etc/exports
#
# See exports(5) for a description.

# use exportfs -arv to reread
#/export    192.168.1.10(rw,no_root_squash)

/media/modular 192.168.24.1/24(rw,async,no_root_squash)
/home/kmandla/downloads 192.168.24.1/24(rw,async,no_root_squash)

Client: /etc/fstab

# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
none                   /dev/pts      devpts    defaults            0      0
none                   /dev/shm      tmpfs     defaults            0      0


/dev/cdrom /media/cdrom   auto    ro,user,noauto,unhide   0      0
/dev/hda4 /home ext2 defaults,noatime 0 1
/dev/hda2 swap swap defaults 0 0
/dev/hda1 /boot ext2 defaults,noatime 0 1
/dev/hda3 / ext2 defaults,noatime 0 1

/dev/sda1 /media/usbdisk vfat noauto,users 0 0

192.168.xx.xx:/media/modular /media/modular nfs noauto,users 0 0
192.168.xx.xx:/home/kmandla/downloads /home/kmandla/watch nfs noauto,users 0 0

Note that those are elective mountpoints, not established at boot. I want the option to run one machine or both without the connection, so I mount them manually, before starting the pair in tandem.

Client: .rtorrent.rc

# This is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
#max_peers = 100

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
#max_peers_seed = 50

# Maximum number of simultanious uploads per torrent.
#max_uploads = 15

# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 0
upload_rate = 240

# Default directory to save the downloaded torrents.
directory = ./modular/hold

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = ./downloads

# Watch a directory for new torrents, and stop those that have been
# deleted.
schedule = watch_directory,5,5,load_start=./watch/*.torrent
schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=100M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
schedule = ratio,60,60,"stop_on_ratio=200,200M,2000"

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
#port_range = 6890-6999

# Start opening ports at a random position within the port range.
#port_random = no

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
#check_hash = no

# Set whetever the client should try to connect to UDP trackers.
#use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa
	
# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
# encryption = allow_incoming,enable_retry,prefer_plaintext

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
#
# dht = auto

# UDP port to use for DHT.
#
# dht_port = 6881

# Enable peer exchange (for torrents not marked private)
#
# peer_exchange = yes

#
# Do not modify the following parameters unless you know what you're doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10
# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10

Of course, there are a thousand ways to arrange this, and mine is not necessarily the best. If you have a different style that’s worth sharing, comment away. 🙂