Is there a file system best suited for a torrent partition?












4















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.










share|improve this question





























    4















    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.










    share|improve this question



























      4












      4








      4








      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.










      share|improve this question
















      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.







      filesystem partitioning ext4 bittorrent






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 13 '17 at 12:37









      Community

      1




      1










      asked Apr 20 '11 at 5:27









      boehjboehj

      1,56021522




      1,56021522






















          2 Answers
          2






          active

          oldest

          votes


















          3














          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.






          share|improve this answer
























          • there might be multiple disks, internal or external, involved.

            – Lekensteyn
            Apr 20 '11 at 14:06











          • Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

            – boehj
            Apr 20 '11 at 14:43











          • In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

            – Laurent Grégoire
            Mar 10 '13 at 12:38



















          0














          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.






          share|improve this answer










          New contributor




          KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.




















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "89"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f36035%2fis-there-a-file-system-best-suited-for-a-torrent-partition%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3














            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.






            share|improve this answer
























            • there might be multiple disks, internal or external, involved.

              – Lekensteyn
              Apr 20 '11 at 14:06











            • Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

              – boehj
              Apr 20 '11 at 14:43











            • In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

              – Laurent Grégoire
              Mar 10 '13 at 12:38
















            3














            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.






            share|improve this answer
























            • there might be multiple disks, internal or external, involved.

              – Lekensteyn
              Apr 20 '11 at 14:06











            • Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

              – boehj
              Apr 20 '11 at 14:43











            • In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

              – Laurent Grégoire
              Mar 10 '13 at 12:38














            3












            3








            3







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Apr 20 '11 at 13:53









            psusipsusi

            31.3k15089




            31.3k15089













            • there might be multiple disks, internal or external, involved.

              – Lekensteyn
              Apr 20 '11 at 14:06











            • Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

              – boehj
              Apr 20 '11 at 14:43











            • In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

              – Laurent Grégoire
              Mar 10 '13 at 12:38



















            • there might be multiple disks, internal or external, involved.

              – Lekensteyn
              Apr 20 '11 at 14:06











            • Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

              – boehj
              Apr 20 '11 at 14:43











            • In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

              – Laurent Grégoire
              Mar 10 '13 at 12:38

















            there might be multiple disks, internal or external, involved.

            – Lekensteyn
            Apr 20 '11 at 14:06





            there might be multiple disks, internal or external, involved.

            – Lekensteyn
            Apr 20 '11 at 14:06













            Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

            – boehj
            Apr 20 '11 at 14:43





            Sorry I wasn't clear with that. The /media/data & /media/torrents partitions will sit on the 2nd HDD. So I'll stay with ext4 then if there's no outstanding file system for this type of workload. Gilles answer to the other question just made me a little curious that there may be a better choice.

            – boehj
            Apr 20 '11 at 14:43













            In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

            – Laurent Grégoire
            Mar 10 '13 at 12:38





            In case you have several hard-disk, you may want to use LVM (wiki.ubuntu.com/Lvm) for a more flexible solution. You can even grow your partitions on the fly by adding more disks later on.

            – Laurent Grégoire
            Mar 10 '13 at 12:38













            0














            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.






            share|improve this answer










            New contributor




            KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.

























              0














              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.






              share|improve this answer










              New contributor




              KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.























                0












                0








                0







                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.






                share|improve this answer










                New contributor




                KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.










                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.







                share|improve this answer










                New contributor




                KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                share|improve this answer



                share|improve this answer








                edited 4 hours ago





















                New contributor




                KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.









                answered 6 hours ago









                KodiThomson50KodiThomson50

                11




                11




                New contributor




                KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.





                New contributor





                KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






                KodiThomson50 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Ask Ubuntu!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f36035%2fis-there-a-file-system-best-suited-for-a-torrent-partition%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    GameSpot

                    日野市

                    Tu-95轟炸機