没想到一个onedrive上传了三回啊三回才上传完所有文件，外加checksum回合总共四回啊四回才整完（恼🤔

所以到差不多1点我才开始转双盘🤔还好这部分还是比较靠谱的，将近15个小时后搞完了🤔现在也许我可以腾出空间来存放cuties impact的新版本，和其他一些乱七八糟的东西🤔

另外昨天晚上压缩截图时突然出现了意外，usb控制器再次失灵，导致我连屏幕都没法唤醒，而且事实上连reset键也没有响应，只有长按power键才能强制关机（恼🤔重启后发现截图压缩完了，而且压缩包完全没有损坏，但它却没有删除所有文件，只有一个盘的东西被删了，还有一个盘东西全都在🤔

对比压缩包里的文件和那个盘没有被删的文件，发现前者居然比后者少🤔那我大概明白是怎么一回事了，非常有可能是因为在压缩的过程中，那个盘又一次掉线了（悲🤔从而导致最终的压缩包既只存储了部分文件，又没法删掉它们里的任何一个🤔

这就非常离谱了，看来我还是得赶紧润X都，不然这些离谱的事情只会一件一件一件发生啊啊啊啊啊（恼🤔

wiebitte

既然度盘转双盘完成了，照例检查日志checksum，结果发现所有文件夹都没有一个匹配的文件🤔wiebitte？

我看了眼日志，发现由于某种申必原因，它这个日志记录的居然是上次整的日志，这次的居然没记录上？按理来说上次的日志早在上次就应该压缩到了某文件里并删掉了，不可能出现在这次🤔反正很离谱就是了🤔

还好我早就知道怎么从discord drive的结果里恢复checksum，重新构建日志（迫真）文件🤔用重构后的日志检查，这次所有文件都匹配上了了，除了一个照片文件夹🤔

这就更邪乎了，莫非是度盘那边出了问题？🤔奇怪的是我将本地文件和onedrive文件直接进行对比，所有文件都不用重传，说明度盘也没有问题啊🤔

那还有可能是discord drive有问题？我随便直接下了一个discord drive包，本地测试发现至少和metadata脚本里对应的checksum是完全一致的🤔

等等，也许还有一种可能：我本地的checksum文件是有问题的🤔毕竟这坨压缩包其实我后面又重新制作了一遍，有可能没来得及更新checksum🤔至少本地的对应文件也算过一遍checksum后，居然和我从discord drive下的文件一毛一样，但它和那个checksum文件里记载的不同🤔

接下来更离奇的事情发生了，我又将那个checksum文件里的.sha256解压到了本地文件那里，直接开始校验，一个一个一个一个文件都通过力🤔等等，为什么sha256记录的是对的而txt记录的是错的？🤔

我又打开txt一看，好家伙，txt记录的也是对的，至少sha256一栏能对得上🤔草，所以搞了半天我只是解压错了checksum文件，把别的日期解压了进去？😅

反正无论如何，这次再跑那个检查函数，所有文件都检查通过🤔现在这场耗时高达一周的图像处理（迫真）终于结束力（悲🤔

昨天上传完两组图片后貌似还是中午，我寻思直接将其就地转三盘得了，好腾出将近200GB干别的🤔反正下一波大规模图像处理（迫真）至少也得等到今天中午或者下午才能开始🤔

所以到现在，它已经完成了下载和上传onedrive，正在转双盘，估计一大早就全搞完了（确信🤔中途我还顺便又下了几个cosplay片子，并将它们全部上传到了法克晴🤔

这次某pt貌似上了一个kujou karen的片子，没错，就是AYAYA梗里喊AYAYA！AYAYA！！的那个萌妹（确信🤔很不幸的是那片子一点亮点都没有，草的时候全程没有露出乳房，而且既然都是kujou karen irl了，连还原一次AYAYA！AYAYA！！都不愿意，某nico chan irl片子还迫真来了三回啊三回niconiconi呢（全恼🤔

所以我还是去看miko chan irl得了（恼🤔我寻思在punimoe的一大堆烂片里，miko chan irl还是拍得有点水平的，至少奶子长得不错，让人想吸（错乱🤔

barbruh

一觉起来开始用新式workflow整256GB图像处理（迫真🤔这次貌似只拍了190GB照片，压缩成大包花了28分钟，再加密压缩成8GB包花了将近16分钟（确信🤔接下来在解压大包到0034的过程中顺便做了一次checksum，花了26分钟（确信🤔可以观察到解压完成前checksum速度降低到了110MB/s，解压完成后才恢复到130MB/s，可能是因为解压过程其实还有解密（确信🤔

接下来再次重启，直接验证checksum，结果两个文件不匹配（恼🤔那我就只能删掉所有备份档从头开始了🤔

过了将近一小时，再次验证checksum无误后，我开始将保存在0034里的大包解压到砂糖盘，并同时开始做源盘、某固态上大包和pe4010上8GB小包的checksum🤔这三个checksum一开，每个的速度降到了80MB/s，源盘甚至曾经一度降低到60MB/s🤔我估摸着这一遍没个四十分钟是搞不完了（悲🤔

但这还是比旧workflow一遍三十分钟好很多，因为旧workflow得整三遍啊三遍（半恼🤔再怎么说，我这一次处理的数据量也是使用旧workflow时的两倍🤔

luminethonk

果然它几乎每个checksum都花了40分钟左右，有的少一分钟有的多两分钟，加上延时大概45分钟应该能搞完（确信🤔再来一波就全搞定了，下一波需要检查目标盘的checksum和0034上大包的checksum，如果它们和上一波结果匹配的话，就说明0034上的大包就是某固态上的大包，目标盘的文件就是源盘的文件，而且目标盘的文件和0034上大包的文件也是同样的文件（确信🤔

其实源盘我做了两遍checksum，这两遍checksum的结果也应该是匹配的，不然它肯定有问题🤔第一遍checksum还会用来直接检验大包解压到pe4010的文件，就是为了将潜在的checksum不匹配提前发现出来，免得在全整完后才发现有问题🤔比如今天我就以前检测出来了（确信🤔

AYAYA

最后一波基本上只用了36分钟，貌似比上一波少了4分钟🤔这样算下来，一坨将近190GB的图片全程需要28+16+26+40+36=146分钟，将近两小时半（确信🤔就算考虑到延时啥的，也不会超过三小时，我记得旧workflow可是100GB图片也要处理三小时以上（半恼🤔算下来新workflow毫无争议地完胜，其实要是没有第一遍checksum不匹配的话，我这玩意还能更早完成（半恼🤔

但接下来在两组checksum之间diff的时候，居然diff出不同的行🤔在我一番迫真排查后，我发现那个屑插件居然用了完全不同的方式来对存储卡里的文件和砂糖盘里的文件进行排序🤔既然如此，将两个checksum文件先sort一下再diff，它们就完全相同了（确信🤔至于那两个txt，可能就不好排序了，但我懒得管，毕竟sha256碰撞的可能性微乎其微，更别说通过传输错误的方式来碰撞（确信🤔

fischlthonk

既然图像处理（迫真）搞完了，接下来就是处理截图了，貌似pe4010的剩余空间应该能塞进去四到五个大包🤔最后一个大包貌似放不进去，但我已经上传了三个照片的8GB包，实在不行将它们先挪到别处得了🤔

所有截图都处理完毕后，pe4010貌似还剩20GB左右，再将两个照片8GB包解压回去，此时它还剩3.5GB🤔看来我居然只差5.5GB，不错🤔这次整完应该不会再整了，以后要是还有截图啥的话等我回X都再说（半恼🤔

thonkrose

貌似还有半个坏消息，砂糖盘哪怕腾完截图也只剩下1.86TB空间了（悲🤔这也差不多意味着再随便来两到三组照片它就进入了退役倒计时🤔我21年初买砂糖盘的时候预计的寿命可能只有一年，毕竟作为那时的二级存储，st6000系列的寿命也只不过半年而已（确信🤔但后面由于各种原因，包括那年猖獗了大半年的chia矿蛆，砂糖盘逐渐从将截图大包转存到0034到将除了照片文件外的几乎所有东西都转存到0034，一直到三级存储体系名存实亡🤔目前砂糖盘的副盘数量已经到了6，估计在未来只会不断上升（确信🤔

我说实话还真的没有考虑过砂糖盘如何退役（或者要不要继续服役）这件事（悲🤔毕竟长期下来，不仅0034，甚至12TB（话说当时为什么没加点钱买个14TB呢）氦气盘都当过砂糖盘的副盘，我现在搞不好哪怕真的买了一个一个一个一个22TB的黑色高级硬盘，估计还是只能去做砂糖盘的副盘（半恼🤔

目前看来砂糖盘逐渐有点早期存储里四号盘的地位了，由于某种申必原因四号盘被我从15年一直用到了1⑨年，所以在我1⑨年初存储升级时，一二三号盘被我光速便乘了8GB备份档，四号盘却原封不动地便乘了主存储（确信🤔

当然1⑨年有的是时间和地方拍照，我也去过114514个地方，作为主存储的四号盘不到一年，来不及塞别的东西而被照片大包塞满🤔估计从此开始，所谓的主存储便逐渐开始沦为了一个放各种大包的地方，从而在若干年之后，在三份啊三份以上在线存储的加持下可以随便降级（迫真🤔

1⑨年还发生了另外一件事，大概是我取消了从13年延续下来的拉丁文数字序数词卷标命名法，而以萌妹卷标命名法取代，因为我那时发现以萌妹来命名卷标时还可以取个对应的盘符（确信🤔主要那时我需要所有硬盘无论用不用得到都得114.514%在线，所以更需要盘符多样化🤔而里面的文件夹结构由于某种申必原因全都是五号盘风格，并没有被我一直递增，这个习惯被我保留至今，换句话说现在无论是砂糖盘还是别的玩意，文件夹结构都是五号盘风格，我甚至可以在它们之间随便切换用途，如果我想的话（确信🤔

这套玩意的高潮大概就是2020年末，那时我有了最新的主存储futaba盘（其实这个是2020初买的）和最新的副存储砂糖盘，而futaba盘甚至有一个六号盘的别称🤔但接下来几年的实践下来，我并没有增设什么七号盘八号盘等新的主存储，毕竟futaba盘相比四号盘更像是堆积大包的地方，除了大包外也就是加起来不足200GB的各种小文件，除了价格超过2000外和我那坨0034没有任何区别（半恼🤔

所以现在演变下来，我逐渐认识到所谓主存储几乎一点用处都没有，还不如买成一坨0034（迫真🤔而所有机械硬盘都上线也不是一件现实的事情，所以目前只有几块固态仍然保留了萌妹（大嘘）卷标风格，比如飞过来盘和刻晴盘（确信🤔剩下的盘由于基本上只用来从砂糖盘转走大包，所以我认为它们不具有独立地位，它们的卷标都是sucrosetemp后面跟一个数字，也不享有盘符，只能挂载在砂糖盘的某个文件夹下（后面又被我挂载在刻晴盘下，以备有时脱离砂糖盘使用），它们就是我经常说的砂糖盘的副盘🤔这些玩意在长期的实践来看基本上逐步彻底取代了主存储，只有砂糖盘作为永远的五号盘存在（确信🤔

thonkeqing

话说接下来几天时间我是不是要搞一搞czech casting了？那玩意我买了之后几乎半个月都没看过，可别像上次那样放没了（悲🤔

今天貌似又到了度盘转双盘的时候🤔考虑到那个小号的会员今天就到期了，我昨天晚上就将那个文件夹下到了大盘鸡里，只不过现在才开始跑转双盘的脚本🤔理论上来说pcs-go无论如何，下载的文件都会放在某个特定目录，而我那个脚本里写的是每下载一个文件就会将该文件从那个特定目录挪到脚本的工作目录再去搞什么checksum和重新上传之类的🤔所以提前从度盘下载文件和脚本运行时才下载文件，理论上这个脚本的表现不会有什么区别（确信🤔

当然，这两种下载法还是有点细节上的差异，其中之一便是直接下载整个目录时pcs-go的特定目录里会出现目录结构，而我那个脚本直接用绝对路径下那些文件时，它们会直接出现在特定目录下，如果不去提前mv文件的话，那个脚本和pcs-go会找不到那些文件，导致它又被重新下了一遍（恼🤔

除此之外，直接下载整个文件夹时可以启用多文件下载，实测5个文件同时下载的速度居然上了500Mbps，基本上可以说是比较满意了（迫真🤔而与此同时单文件下载速度降到了比100Mbps还要低，看来度盘也逐渐onedrive化了（半恼🤔

wiebitte

接下来开始跑度盘转双盘脚本🤔几乎一切顺利，脚本按照预期的方式跳过了下载这些文件并将它们挪到了工作目录，checksum和discord drive也能跑🤔除了guilded上传只有几百KB/s🤔

wiebitte？吓得我又重启了一遍大盘鸡，这下终于正常了🤔这可真够离谱的，看来以后搞这些大的，在vps控制面板里重启一遍还不够，还得在vps里也reboot一遍才行（悲🤔

thonkeqing

自从我连不上某台dedicated server（大嘘）之后，最近没啥事干（迫真）又在翻着看各种win板🤔现在貌似有一个富士通的q704有点意思，u是4300u，4+128，大概550到600块钱之间，反正比几乎相同配置的索尼duo11/13便宜多了（确信🤔我听说parsec作为客户端用的最低配置就是hd4000，而这些win板用的是hd4300，所以也许它们能跑得动至少1080p的parsec串流（确信🤔

它还有一个8GB内存款，用的是4600u，但我感觉那玩意就不值了，因为价格直接就是猴版的两倍，而且parsec至关重要的图形性能并没有什么提升🤔买它还不如买比较新款的q738，尽管价格是q704的整整三倍，但图形性能不知高到哪儿去了，parsec串流4k搞不好都没啥问题（确信🤔

我之前还关注过一个叫做q506的型号，用的是z8550，但现在感觉它和q704的价格其实差别没多少了，反正atom全系包括z8750都没法跑parsec，还不如加亿点点钱上q704（半恼🤔但如果不指望在平板上玩parsec的话，富士通其实还有一个z3795的老平板，价格基本上只有300块钱不到，甚至可能低到200左右，这不比什么中柏mini4好玩114514倍？🤔

其实有意思的是，无论是atom的3系还是8系，都有一定的图形能力，比如可以迫真运行illusion的部分3dhentai游戏🤔只不过帧率表现就不好说了，我之前在一款iwork7上迫真测试playclub，只有个位数fps，我记得1还是2来着🤔当然我估计打上一大堆插件跑旧illusion游戏也许勉强能玩，但那时我没测过，毕竟aa2如果不用那个改善了包压缩算法的魔改版的话占用体积能到极其夸张的20GB，可不是那些小平板能放进去的（悲🤔

甚至，parsec都能作为客户端连接上去，只不过会卡出⑩就是了🤔相比之下，某j1900可是连parsec连都连不上的纯垃圾，问就是host不支持硬件编码（全恼🤔

终于到了可以onedrive转度盘的时候了🤔一般来说由于某种申必原因，无论是本地上传onedrive还是onedrive转度盘，我都喜欢选择偶数天搞🤔

自从上次github actions转度盘慢到十几MB/s甚至比本地还要慢后，我基本上对从外网上传度盘不抱任何期望了（悲🤔但今天实在是顺利得离谱，要不是我记录了日志简直不敢相信这是真的，每个8GB文件用了不到60秒甚至5⑨秒，而且基本上都是一次过，后续的上传尝试全部被跳过（确信🤔最后91个文件包括下载验checksum和重新上传只用了228分钟🤔

这什么神仙网络🤔更别说在我自己的vps上甚至checksum速度都变快了至少一倍，github actions上需要半分钟的话我自己的vps基本上15秒就搞定了🤔这也许是我上了玄学的结果，毕竟和本地上传onedrive前先重启一遍光猫和路由器一样，我在vps上搞网络玩意之前也会先在vps管理后台执行一遍重启，哪怕我压根就没有被限速🤔这大概也是为什么这台vps不太适合挂pt🤔

当然前段时间做的onedrive转双盘也不算慢，13个文件用了109分钟，这要是按照91个文件算的话大概是763分钟，也就是十多小时（确信🤔而且其实onedrive转双盘我就不讲究啥时候整了，本地刚上传完就开始整也不是⑧行🤔

thonksette

现在看来这个时间其实是完全可以接受的，度盘如果每天半夜都是这么给力的话，我寻思处理完800GB的标准（大嘘）数据包也就一晚上的事🤔既然如此，以后我应该就不用雷普什么github actions了，这玩意又麻烦又经常容易中途出事，onedrive和度盘多线程时都有可能掉链子，要么429要么上传半天只能上传一个0字节的文件，而一旦这些破事发生了，我就得想办法找到缺失的文件再搞一遍，这样就会浪费掉大量时间（恼🤔

也许现在我还可以将其整成onedrive转三盘，但现在我宁肯重新从onedrive下一遍文件也不太愿意将它们合并，毕竟度盘上传不确定性实在是太大了，不像双盘基本上是确定的，我甚至对其完成时间都能有一个预期（确信🤔

但无论如何，我可以肯定的是，应该是从今年四月份起搞出来的，github actions的这种公车私用的旁门左道，真にま结束了（吴慈悲🤔它起源于我在某恐婚群里的一次玩笑，目的是迫真演示从nyaa上下种子是多么的容易（大嘘），但最终那个一开始只能用来下种子的所谓通用antics被各种魔改成了可以用来做任何事的真·通用脚本，并在接下来几个月内被用来下了不知paysites的多少片子🤔

在后面我发现了这种土法雷普github actions的弊端，想开发出叫做project cosette的全自动化github actions雷普系统，甚至进行了十次甚至⑨次技术选型的迫真论证（其中几次甚至是在考场上做的🤔但极其不幸的是哪怕到今年结束，我也没能撸出成品（悲🤔

而在github越来越魔怔的风控之下，在土法雷普的所谓ruantics存活时间只能以分钟计的当下，project cosette不再是锦上添花的点缀，而是下一阶段彻底雷普github actions时不可或缺的infrastructure（确信🤔尤其是如果我明年某个时间还想整点比如将adulttime可能超过50TB的片子在一个月之内全部撸下来（甚至全程无人值守）这样的狠活（半恼🤔

luminethonk

另外我的两个远程开关机设备也到了，先去调试那个usb版🤔安装过程还行，它貌似只提供了一个远程按键，不过有四条跳线，两条接主板的power sw，两条接原来的电源按键，这样它既可以保留原来按键的功能，也能远程遥控（确信🤔由于某种申必原因，它全系都没提供reset sw，但我拆开那个迫真nas后发现它原来也没接reset sw，那没事了（确信🤔实在不行再买一个这玩意接reset sw也不是⑧行，但我就懒得折腾了🤔

现在我的迫真nas已经具备了在有网络的任意地方远程开关机的能力，而且它被配置成只要开机了就能立即启动上面所有远控和clash（确信🤔主机那边，考虑到我这几天要忙着impact cuties，实在不成明年慢慢配置，反正我应该还有五六天，装个新系统啥的最多一天搞定（确信🤔

另外我最后决定不去折腾什么1068e古董了，现在sas2308也就65块钱，闭眼买就vans了（确信🤔效果好的话以后我连阵列卡都不用到处带着走🤔

今天又是一个一个一个一个野兽节啊啊啊啊啊🤔处理某个度盘小号的时候，一不小心cd错了目录，或者说cd压根就没有执行，然后我来了一句rm *，好家伙，整个盘的东西全没了（全恼🤔

所以我只能将它们全部恢复出来，并花了11451.4秒重新修改它们的时间戳🤔其实度盘这玩意有两个时间戳，创建时间是不变的，修改时间这玩意可以任意变🤔按理来说完全就没有任何修改度盘文件的方法，但它居然就是有这么一个时间戳，比如目录重命名和里面的东西有改变（比如删了一个文件或者保存了一个文件，或者重命名一个文件），就会变化🤔而如果给一个目录重命名或者将它从回收站里恢复出来的话，里面所有东西（包括子目录，和里面的文件）的修改时间都会便乘目录被重命名或者恢复时的时间（严格点来说有一个一两秒的延时🤔

更离谱的是，之前设置的onedrive转三盘，8个线程里7个都跑完了，只有第一个线程卡在那里，只处理了四五个文件，而且也没有输出日志，直接就卡超时了（恼🤔

那我只能将这一整个线程里的链接分成8个线程重新搞一遍🤔最后统计下来，onedrive和guilded都完成上传了，度盘那边居然有五个文件是0字节，一看日志，草，这些文件在最后合并分片的时候发生了连接超时，而它居然没有重试的能力，wiebitte？🤔

也许我可以直接从本地上传这五个文件，但在此之前我更愿意再跑一遍之前写的onedrive转度盘脚本重新上传它们，毕竟github actions还是快很多（确信🤔

除此之外，我在onedrive上传三盘或度盘的脚本里还加了一句sumfile，就和我本地处理这些文件时的sumfile一毛一样，它至少可以算个md5出来，这样通过对比日志文件和我本地的sumfile文件，我至少可以知道从onedrive上下载下来的文件是不是我本地曾经存在的文件（确信🤔况且sumfile除了文件md5外，还能算出文件前256KB部分的md5，反正我寻思由于文件下载过程中出现故障导致这两个md5都能保持不变的概率低到可以忽略不计，所以基本上sumfile能对上，就说明onedrive下载下来的文件等于我本地的文件（确信🤔

thonk

纯度盘上传脚本就没出什么岔子，全部上传完了🤔对比它和三盘脚本，它们度盘部分唯一的区别，居然是旧脚本设置了32线程，而新脚本设置了40线程，就这个🤔

但这次跑脚本时onedrive至少一点事都没出，一次下载错误都没有，剩下两个drive也没出问题（确信🤔那么下次跑脚本时也不用多说，度盘上传线程调小就vans了，先调到32，还是不行就降到24🤔