Google 前几个月公告了 Backup & Sync 以及 Drive File Stream 这两个新的程式。搭配无空间上限的教育版 G Suite，前者能达成无限备份的效果，後者我猜想或许有机会可能帮助长期 PT 的冷门种作种，但几乎没见过国内外的相关讨论，因此在这边贴出来看大家是否有经验： 对於作种时间能换成积分的PT站，作种越久越好，可换成上传量。华人的各站都有积分制，而国外的 BTN、PTP 的积分制下，冷门种作种时间越长，每个月自动产生的积分量是随作种时间成正变的增长。 这些长期作种的冷门种，其实很少有人上传，占硬碟空间，但删了又可惜。 Google 的 Drive File Stream 能让人将档案放上 G Suite，不占本地硬碟空间，mount 成自己电脑的一个碟，看起来就像本地碟，用档案总管就看得到了，用到其中的档案时，Drive File Stream 会自动将该档抓到本地，就可使用了。 因此我想到，如果硬碟空间不够了，与其将作种的档案删除，是否可将已经极少人在存取的档案移至 Drive File Stream？只要用 BT client 的 set download location 换个磁碟即可（例如从 D:\Seeding 换成 G:\云端磁碟\Seeding），在外界看到的还是一模一样。 当然，有人要那档时，系统得先从云端下传再上传，速度会很慢，但这种冷门档本来就很少人会下载，速度本来就快不起来，留着比起删除还是好些？ 看有没有人试过，有什麽心得？长期来说可行吗？ 我摆了几个档案几天，目前的片面经验： 1. QBtorrent 没问题，utorrent 无法移至 Drive File Stream 的目录下，可能是因 Drive File Stream 的目录有中文。有办法将 Drive File Stream 的目录改为英文吗？（我改不了目录名。） 2. 如果偶尔因为网路问题或是 Drive File Stream 没开而导致 file error， resume 就可以恢复正常。 3. C槽是SSD的人，记得将 Google 的各项暂存目录改为 junction 连结到HDD上，以减少对SSD的不必要的写入动作。（这无关PT。） -- -- ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/P2PSoftWare/M.1512970951.A.378.html 的确什麽碟都有灾情，重要档案实在得备份啊 :Q SSD是不怕震，传统SSD一震就容易坏。 但SSD的写入有寿命，虽然说那寿命是超过一般人用的写入次数。 BT对磁碟的写入量真得蛮惊人的，不只是写档本身，还有储存各个torrents状态的档案，像Qbittorrent因为每个种子是一个档案，相当於每几分钟就重写入暂存档，我之前作种五千个种子时，每十五分钟SSD会被Qbittorrent操到满载40秒。後来看了一下SSD管理软体，一个小小的SSD竟已写入几十TB的资料量了，赶紧把 QBittorrent 的目录 mklink 到可储存状态的 RAM Disk 上，关机时才自动存回SSD上。 Utorrent 由於所有种子是同一个暂存档，因此理论上暂存档没有写入得像Qbittorrent 这麽凶。 另外，我们公司给客户有用大台的伺服器，用最贵的企业级的SSD以及企业级的HDD，也是照样一台接着一台坏，这些都是机率问题，只能用RAID及备份减少灾情。 谢谢 fromPtoZ 提出的这议题，的确是须要多探讨这点。目前我找到的 GD 的限制如下： There is a bandwidth limitation per viewer and per owner, and a limitation on the number of times a document can be viewed. The limits are 10TB/day and 50,000 views/day with bursts up to 900/min (15 QPS) per document. Also, in June 2017 a quota for creating blobs of 100Gb/day was established. It’s possible to create files of bigger size, but after this quota is exceeded all subsequent blob creation operations will fail. 一般 Hinet 光世代不会超过流量的上限，因此只怕单档 100GB 的限制，以及 50,000 views/day with bursts up to 900/min (15 QPS) per document 的限制。 後者我想就是 fromPtoZ 提醒的议题。不知道有没有人知道在 Drive File Stream 的使用模式下，从 GD 端看到的是一个 request 然後把整个档或档案的某一大段搬回家，还是每次是一小点的 request? 先前我个人猜比较像某档整个搬回家，但这样的缺点就是某人纵使只抓一小段，整个几十GB的档案就会被搬回家，有点浪费频宽 XD 只适合存真正冷门的档。 如果是一次只读取档案的一小部分，虽然耗的频宽就很小，但就会有 fromPtoZ 提醒的这个问题了。 还好超过限制後 GD 只是自动中止服务24小时，不会停权？因此看有没有仁人志士能测试看看 XD 刚终於找到相关讨论了，在PTP上，有帐号的人可参考： http://0rz.tw/2acMs 去年的讨论，是基於 Amazon Cloud Drive + rclone 加密。可以 random read。 毕竟是PT站内讨论，不方便PO出原讨论内容，但许多人都表示成功，有人在ACD放了30TB作种了六个月，没有任何问题，并提到有其他人在GD放了160TB没问题。 不过不确定那时GD的限制是否有现在这麽严。 另一方面，就我目前的观察，Google File Stream 是全档下载到暂存目录，因此不适合作种特大的档案（档案传回电脑就要花很久），只适合作种几分钟以内能下载完的档案。 目前我在本地作种超过一万五千个档案，过阵子会慢慢将小档搬上去试试。 fromPtoZ 提到朋友测试後被挡，我猜有三种可能性： 1. 若直接以 GD 的连结公开分享出来，而不是经由自己电脑，立刻被档。（但这不是在PT作种，应该不是站友提到的状况。） 2. 在PTP讨论串中，成功的人几乎都是用 rclone，用其它的方法问题不少，有可能 netdrive 和 google-drive-ocamlfuse 的效果没这麽好。 3. 或许那时 GD 的限制较少？ 单就 Google 的限制来看，我估计用 GD File Stream 来作这事，不会遇上 Google 的限制，因为是整档下载，读取次数不多，只是由於整档下载，因此不适合大档，而且没有加密。Google 目前为止都没有取缔未公开的版权档案，但未来难讲，这是一个风险。 用 rclone 搭配加密应该还是较好的方法，只是这样子 random read 就有可能遇到 fromPtoZ 提到的 Google 限制，需要有仁人志士仔细计算或测试。 ※ 编辑: lnyan (106.104.121.159), 12/13/2017 19:03:47 感谢 hangsh 前辈的金玉良言! 的确玩PT不划算，尤其外站更不划算，现在 Netflix 这麽成功了，PT在没落... 我是刚好学CS，所以手痒当兴趣玩一玩，习惯性想找最佳解，然後会写程式所以事半功倍。只是凡是作为兴趣的东西通常是浪费钱和时间 :Q 也觉得蛮幸运的当初学电脑 XD 在一头热的时候，能有人提醒避免浪费太多时间，是蛮重要的。谢谢！ 感谢高手的分享！ 使用 Google 新的二套系统 (Backup and Sync, 以及 Drive File Stream）到目前为止的感想（无关PT，单纯从备份等方面来看）：还是用 rclone 较好，Google 内附的系统还是太阳春，且不太稳定，使用 Google 内附那二套唯一的好处是省事。 ※ 编辑: lnyan (220.133.14.84), 04/20/2018 00:38:03