Bdtyktl

Following on from an excellent answer provided by user Gilles, I'd like to ask whether there's a file system particularly well-suited for fairly heavy torrent use.

Soon I'll be setting up an Ubuntu box with:

• / [ext4]


• /home [ext4]


• /media/data [ext4]


• /media/torrents [?]

Normally I'd make the /media/torrents partition ext4 without considering other options. However, in light of the information linked to above, perhaps there's a better alternative.

The proposed /media/torrents partition will be read and written to 24/7 but will only ever reach ~85% of the partition's capacity.

Ext4 will handle it just fine, which is basically while Gilles said. There also is little to no benefit to breaking the disk into 4 partitions. You most likely will be better off with at most / and /home partitions.

Short answer: Use Ext2 on a torrent cache partition. Also use the following mount options: noatime,nodiratime,nosuid,noguid,noexec

Long answer, well... dare ye read it?

(Also, this forum SEVERELY botched the nice formatting and spacing... thanks)

If you are able to, I would suggest you split your drive into two primary partitions. I know of a setup which is working well that has done this on an old laptop with a 160 GB HDD. The HDD is split 60GB mounted / with the system all loaded on it. The second partition is 100GB, mounted to the first at point /tor . The reason the frist partition is so large is this laptop is also hosting Deluge, CouchPotato, SickRage, HeadPhones, and Emby. These use up a fair amount of cache for metadata downloads (for the 4TB attached USB drive of media)

The Torrents directory /tor will require high amounts of random reads and writes, to about half of its contents, simultaneously, all the time.... Until an SSD gets loaded into the second drive bay it will be limited to sharing this horrendous load with the server portion.

EXT4 is a JOURNALING file system, which means it tracks all those extra little changes, writes 'em down. BUT, you could really care less about this feature, any checksum features, anything which records the 'modified' date each write that occurs to a file, just adds to the I/O count, increasing lag. You don't want redundancy, nor do you worry much about data integrity or longevity. There is a setting in most torrent applications which re-checks the group of files it believes it has just completed, for errors, before moving those completed files to a "finished" folder (or, another drive). For Torrents, you will be GLAD to REDUCE THE SYSTEM LOAD by switching this second partition to a DIFFERENT file system (which I am presently looking into for you), AND additionally there are more options you can use.

When you are partitioning Ubuntu for the first time on a computer, or a new drive for example, you can choose how that partition or drive is used. Partition Type: Ext2. 2? not 4? you ask? Well, 2 is non-journaled. 3 and 4 are. Plus I googled a thing... http://www.linux-magazine.com/Online/Features/Filesystems-Benchmarked so check it up. These values are not true in every case, but for what we need it is pretty great. We need HIGH throughput of SMALL RANDOM writes. Ignore the first graph, it is reads, and sequential at that. Second graph, Ext2 is right up there (only thing I would suggest is faster would be the XFS). Sorry look at the FOURTH graph, my bad, second graph is of SEQUENTIAL WRITES (which while tormenting you will NEVER have), Instead, graph 4 shows a comparison of 32MB RANDOM WRITES. Which is EXACTLY what you want the fastest performing drive on this list for (And for sequential reads when it is completed a download and about to move it).

I will say I was considering tying to figure out how to mount a SWAP partition in a similar fashion to how it works.

Now its down to the little things, all the tiny extra IOs that don't make any difference when doing normal filesystem operations. DATES. "Last Modified" or "Last Accessed" and "Last Saved" and "Last written to by" and so on and so on. Each time your torrent client flushes the RAM cache to disk, all of those files which just received a 500kb-4MB chunk, need to update those four dates, and your SUID (user ID) and (guID) group ID. And guess what? your drive (if its Advanced Format), has either 512KB sectors, or it has 4196KB Sectors, which means if something in this sector changes, it will re-write the ENTIRE sector. (or maybe I am confusing it with partial fills of sectors, if so apologies). But basically your single write of 500ish KB of data, now has to update 5 pieces of metadata spread over the file or drive (fragmentation), and EACH of those 5 pieces needs the arm/head to find its location, read the original data, send it to the processor, have it processed, modified, and returned, then re-written to the disk, on EACH OF THOSE 5 EXTRA SECTORS. So how do we stop this? I am not sure, in the mount point options but there is probably an option. As far as a NEW UBUNTU setup goes, go into the "Mount Options", and select the following:
noatime - no access time - do not update inode access times at each access
nodiradate - no directory access time - do not update directory inode access times
relatime (I do not know what this option does)
nodev Do not set this, I think it basically puts a symbolic link in every other drive, at that same directory structure location, and basically gives them the go-ahead to redirect all their writes to said symlink file to this drive you are mounting. And vice-versa. But could be wrong.
nosuid - Ignore set-user-identifier or set-group-identifier bits (useful if you have two daemons running as separate users that need a file passed between them)
noexec - do not allow the execution of any binaries (This is a good safety idea, but if you are downloading much software rather than movies and or tv, music, then I suggest you don't use this as you will quickly get annoyed at it). Great for nullifying many threats to automated download systems though.
ro - ....you don't want this
sync - I believe has to do with paired, spanned, or arrayed volumes over multiple drive,s it will try to read_write things in proportionate cycles
usrquota - thankfully if the torrent partition fills up 100% the drive is still accessible and doesn't lock up entirely, so we don't need this option.
grpquota - same as above, not needed
usr_xattr - http://manpages.ubuntu.com/manpages/xenial/man5/attr.5.html (Extended Attributes)

Keep your files close to the root of the drive or partition, shorter paths mean less path lengths, means shorter indexes, and possibly (not noticeably) quicker I/O times.

Great resourse here by the way:
http://manpages.ubuntu.com/manpages/xenial/man8/mount.8.html

Things that speed up your torrent cache drive:
- Use a non-journaling FileSystem (Ext2)
- noatime, nodiratime, relatime, nosuid, noexec.
- Use a short mount point, or directory (the less ups and downs through a hierarchy of directories your software has to make, the better)

On that mount manpage, there are a LOT more options to go through. If you use the ones I have selected (by only going through the new partition menus on a ubuntu install) then your torrent client will need to survive not knowing the dates of each chunk, it will need to be content writing this data at the end (which the FS usually does all the little dates anyways, so we are good there), you will not be able to run any downloaded software from that directory, (move it to another partition), The contents of the partition would essentially have a 666 access code, everyone can see, read, write, delete, copy each file and directory within this partition. Though you may may be able to set the permission of the mount point (/tor) to ONLY allow your client and yourself. Because with no UIDs or GIDs, the filesystem will not care who accesses the things. (Very bad for your privacy, risk of spyware, the NSA, and all those copyright infringement enforcers all seeing EXACTLY what you have on your drive. But again, may be possible to block all other access from the mount point. Any other items you have on a split drive, will be at a greater risk of failing along with that cache drive when (not if) it goes. Your torrent client will (if settings enabled) re-check each download as it is marked complete, for its completion, and find any problems in the files, correct them (or throw error and you will need to manually tell the client to re-check the download), usually before moving it (according to completion moving rules). You will want to keep as many torrents seeding afterwards as you can, rather than relocating them right away.