vmdk文件越来越大,没得治了?


  • CORE 网格教授 OpenFOAM教授 管理员

    装的vmware虚拟机,这东西太占地方了,越来越大。

    https://blog.csdn.net/u014552102/article/details/80976431



  • 是吧,东西放多了,然后删除也没用,要不重新弄一个吧。。
    之前没注意空间,结果占用我整个ssd然后用Diskgenius读取vmdk把能用的都拷贝出来了。
    另外如果总挂载的话会占用过多空间


  • CORE 网格教授 OpenFOAM教授 管理员

    嗯,我重新弄了一个.. 离不开win,还得用linux,只能用虚拟机啊。虚拟机还只能放在SSD(为了性能)


  • 自由表面模型副教授 OpenFOAM副教授

    @东岳 以前我也是虚拟机,后来还是觉得不方便,就又买了台二手工作站,现在桌上两个屏幕,一台linux mint,一台win10,linux下的算例文件夹局域网共享,通过synergy共享一套键鼠。除了synergy偶尔失灵一切都好。


  • CORE 网格教授 OpenFOAM教授 管理员

    之前也用过1星期,但是有的时候配套配不上,应该是我家局域网的问题,有点发憷了。
    不过synergy解决方案挺好的。如果能稳定的话,我愿意再尝试一次!



  • @东岳 要不整个NAS,家里建个服务器好了,虚拟机只用来算case,文件储存都存到别的地方,千兆路由器够用了。


  • CORE 网格教授 OpenFOAM教授 管理员

    @星星星星晴
    文件系统这面怎么搞。我硬盘做成windows的nfts格式,拷贝linux的数据总是丢或者各种问题。做成ext格式的硬盘,windows还不支持

    到现在我windows下面还有个linux目录一直删不掉

    0_1544176161663_捕获.JPG


  • OpenFOAM教授

    @东岳

    • NTFS不支持从ext文件系统下拷贝过来的软链接文件,所有lnInclude下的文件都会丢失。
    • NTFS的文件名不区分大小写,所以OpenFOAM中的一些文件名相同但区分大小写的文件没法共存。

    只能把 OpenFOAM 放到 WSL 里面了:mianmo:



  • @东岳 好像我们用的方法不一样,你是不是把硬盘挂载出来了?
    然后再windows下读取?
    我觉得这样好慢,而且特别不稳定。我试过一次再也不用了。

    那次因为虚拟机文件太大,无法打开,然后我是用DiskGenius 读取vmdk文件,直接在里面就可以提取出来,没有涉及到文件目录的情况。

    或者你提前压缩一下,.tar.gz就应该不会出现文件命名储存的问题了。

    0_1544184200052_c0972e09-2f0a-42a7-8ba5-e9543904886f-image.png

    vmem文件是休眠缓存文件,异常关闭虚拟机后,我是删除过这个,没啥问题(谨慎)。

    0_1544184513787_4c1e219c-c6d3-42ff-8b44-bf2ee8c526ca-image.png

    0_1544184536550_fc99323a-0577-4cbb-b815-9a0bf702ecaf-image.png

    然后家里有个NAS,就把所有算例后来都保存到NAS上了。



  • 大家都在分享,我也提供自己的解决方案。

    以前有一个玩具笔记本,装 arch + emacs, 编写算例文件,以及一些处理脚本。 用 GitHub 来管理算例文件,注意写好忽略文件就好。

    传送文件以前用 transfer.sh 特别方便,现在不行了。用 ftp 之类工具传送网格文件。在集群上用 GitHub 来同步算例并计算。集群上的硬盘资源还是相对丰富一些。但是有时候,也会出现一些问题。我最困难的时候,面对 30TB 的数据文件(因为自己的无知),管理员善意的提醒,面对兼顾数据分析和备份的需求,我发现 GoogleDrive 是一个不错的替代。 对于教育用户,Google 宣传无限容量!

    然而,真正我在使用的时候,发现并不是这样, Google 对容量没有做限制,但是对 API 请求要求做了手脚,最终每天我只能以 700+ GB 数据量上传。

    经过了这些,现在我做计算的时候,特别注意数据的压缩,再也不想被友好的管理员善意提醒了。



  • 发完帖子,我发现 transfer.sh 复活了!!! 太棒了!

    Don’t Panic! transfer.sh will live on!
    After running and supporting transfer.sh for 4 years on my own, I’m happy to announce we are partnering with Storj Labs to keep the project going. From day one, the transfer.sh code has been open source. Storj has a commitment to open source sustainability and reached out to help us find a way to keep our project alive. Stay tuned for updates on the partnership with Storj, but for now, please continue to enjoy the service!
    Blue skies, Remco Verhoef