bruhbara.20.11.04

昨天晚上听说ubisoft的watch dogs legion源代码被泄露了,500多个GB,我借助迫真搜索技巧找到了torrent,然后便乘了黑客(迫真),到现在差不多下完了,问题是这真的是个559GB的大文件,我不知道怎么转存到discord drive上🤔

这可真是蛋疼,rar小文件打包需要这个体积的1.05倍作为临时空间,而我只有210GB🤔

UPDATE:最后将32000个discord标准包(以前是8后面六个0,现在是8MB-114514B)转到另外一个vps后才完成打包,然后我发现另外一个vps的硬盘简直就是金刚石盘,做个checksum慢到了8MB/s🤔

所以并行discord drive是不可能的,只能再迁移过去,前后折腾了两天才传完discord,链接文件21MB,我以前的脚本只会无限循环,但新脚本遇到链接文件大于discord标准大小后会尝试压缩🤔

然后我实现了一个迫真排序脚本,用grep来在链接文件里对指定part号进行筛选并保存到新文件里,这样新的链接文件就是有序的🤔而且它肯定可以完全并行,每个线程grep处理它的区间里的part号就可以了,然后用cat *合并,拿回本机后24线程处理有七万条链接的ubisoft源码包用了34分钟(其实之前的迫真benchmark表明10线程和24线程差距不大,100线程反而会导致部分线程等待,但理论上来说它就是分成了114514个线程,每个线程之间也完全独立,不依赖任何线程的结果🤔

当然更大的并行度也是完全可能的,但需要更改discord drive的调度算法,确保每个线程上传前被分配到的文件在线程间是有序的(比如5000卷10线程,线程0分配的是1-500,线程1分配的是501-1000),这样每个线程内部排序(其实为了将需要grep的部分减少至之前的线程数分之一,在discord频道备份脚本里讨论过这个问题)之后合并起来仍然有序🤔问题是discord drive是通用脚本,前身是递归列举音乐目录的脚本,分卷压缩包只是其用途之一而已,它还有转存远程文件甚至搭配rclone转存其他网盘文件等作用,所以这个改进会带来逻辑问题,更别说我不是什么时候都需要转存600GB文件并排序🤔

其实之所以我需要排序,是因为我本地固态只有200GB可用空间,所以下载它时也需要按分卷压缩包的顺序下载,先下后面的分卷并保存到另外一块机械硬盘上,然后从后往前下,到最前面的分卷下载完成后才能从第一个分卷开始解压,然后依次换上另外一块机械硬盘上保存的后续分卷🤔所以为了分块下载时保持有序,链接文件必须排好序🤔之后就好办多了,每30000行对应10000个分卷🤔

从discord直接下载时每一万个包会有几百个包下载失败或者checksum对不上,可以通过一个简单的checksum脚本排除,甚至开24线程都可以,然后用grep -v来筛选结果不是“成功”或者“确定”或者“OK”的行并输出part号,然后将所有输出的part号用上述排序时的方法grep出新的aria2链接文件,就可以重新下载了,再重复上述过程直到所有文件checksum通过为止🤔

一天半后那个580GB的ubisoft.7z就出现在我的某块机械硬盘里了,用p7za列举文件能够花掉1.6GB的内存,难怪我没法用我的vps做这事(其实就是因为我没给设置swap🤔

光里面文件的列表就有840MB那么大,我大致看了下,反正里面没给够工具链,拿这些玩意是别想编译出wdlegion的,也许里面好像有个已经编译好的exe,但由于7z包必须一次性解压,不像rar可以只解压一部分,而这些文件解压后有1.01TB,我可没那么大的固态,所以只能搞到这儿为止了🙃

ps. 其实wdlegion好像不怎么好玩,我还是接着玩cuties impact去吧,至少后者可以4k🤔

发表评论