fatal error:invalid gz file,exit
ferstar opened this issue · 8 comments
解压一个常规gz文件时遇到这个错误,这个gz文件是正常的,就是大了些,25GB,希望排查下
$ ls -sh /resdata/SCT_DATA/data_deliver/JY_combined_R2.fastq.gz
25G /resdata/SCT_DATA/data_deliver/JY_combined_R2.fastq.gz
$ zcat /resdata/SCT_DATA/data_deliver/JY_combined_R2.fastq.gz | head
@E00552:208:HNJFYCCXY:8:1101:2351:1379 2:N:0:NGAGGCTG
NATCAGAATGAGCTGGTGGGAACCTTGGGCAGCCAAACGGAGCGGCGTTCTGCACCATGTCCCATCCAGTGCTGCGAATCCACGCCCCGCAGCCCTGCCCCCCCGCGACAGCTCACACCATGGCTCGAGGACAAGGTGTTATCCCGACAC
+
#---<A-FJF-F-7--7-7-7-7F<F-<J---7AAAF-7---A-F--7-7-7-<-7A-7AJJF-AA<7-7-7-A--7---7<A---7--7A<7-7---7-7F7-)-)7)7-A<)--AF----))-)-))))--<-----7---7-)))))
@E00552:208:HNJFYCCXY:8:1101:2392:1379 2:N:0:NGAGGCTG
NCTCATCCCAGCAGGCCCTCCCTTAGCTGAGGGAATTCTTTTTCCCCTCCCTCCACCGACAAATATTGACAGGCACCCACCGAGGATGTGCAGAGCTCAGCCGCGGCTGCGGGGACTCAATTTGCAACAGACATGGACTCCCCCCTCACG
+
#<-A-----7----7----7F---<-7-<--77-<--A<--7-<7<A--A7-7A7AJ<----7---7<--<FF-77-7-<J-A-77-7FAA----7-7A--<-)-)))-))))))-)7---------7------7--7-)))))))-)))
@E00552:208:HNJFYCCXY:8:1101:2514:1379 2:N:0:NGAGGCTG
NAAGAATTTCAAAGCCTTCGCTAGTCTCCGTATGGCCCGTGCCAACGCCCGGCTCTTCGGCATACGGGCAAAAAGAGCCAAGGAAGCCGCAGAACAGGATGTTGAAAAGAAAAAATAAAGCCCTCCTGGGGACTTGGAATCAAAAAAAAA
压缩进度到多少的时候出现这个提示的?
我们觉得很有可能是gz数据的中间,或者尾部出现了数据错误。GTZ对 fastq.gz的的压缩,是边解压gz,边重压缩解出的fastq数据的,这个错误提示,意味着,GTZ在解压gz数据过程中,发现gz文件有错误。
您是否可以尝试使用 gzip 完全解压一次,看一下,是否gz数据本身真的完整?
(如果gzip解压确定没有任何问题,请回复我们,我们将专门派工程师跟您取得联系以解决这个问题。)
(PS. GTX.Zip 本身就是为大型数据设计的,这个大小对于GTZ不是问题。)
@superligen 这是显示到100%时出现的错误,实际这个进度显示很任性啊,进度100%还能往上继续蹦的
我们磁盘阵列崩了,联系厂商换硬盘得几天时间,暂时没法测试了
ok, 对于 fastq.gz的文件,你会经常看到进度超过 100% 的情况,这个是因为gz数据本身不记录到底有多长(gz里实际有一个size,但由于是32位的,所以并没有什么实际意义),因此,我们无法准确的估计进度,我们的进度数值是根据 实际解压出的fastq数据大小来估计的。这块我们后面会寻找一个合理的方案。
等你们盘阵修改好了,你可以测一下,很大概率是这个gz数据损坏了。
另外,我们配合阿里在推动基因数据云上存储,10TB容量的OSS 3年,只需999。这个可以很肯定的说是赔本的。在配合 我们的 www.gtz.io 的 云数据压缩服务,你可以存下 几千个 全基因组数据。
PS, www.gtz.io 云上数据压缩服务,使用的是我们的企业级压缩技术,一般情况下,比你现在用的public版压出的数据再小一半,通常是gz数据1/7 ~ 1/4大小。而且是完全免费的,非常划算。
关键是,完全不用担心数据损坏。
上云的方案跟老板提过,因为下行流量费用和数据敏感性已经被老板否掉。
不过对GTX.Zip离线版倒是很有兴趣,另外不知道什么时候发布支持Windows平台的版本,很是期待啊。
离线版,我们正在紧张测试。简单调查一下,
1、你们对Windows 平台的工具最大期望是什么:命令行还是GUI界面?
2、你们的Windows平台是什么Windows 系统?运行这个Windows系统的机器是多少核心,多少内存的?
3、大部分的生信分析程序应该都是Linux的,为什么你们期待 Windows的产品?
非常感谢!
- GUI界面最好,因为用户比较小白。至于我们自己用的话无所谓GUI,也无所谓Windows,反正服务器都是Linux;
- 现在一般都是Windows10了,配置方面就是普通电脑,一般4核心8GB左右吧;
- 期待Windows的产品是跟我们业务特点相关的,简单讲下就是我们可以帮助合作用户深度分析下机数据,一般用户测完序拿到一大坨fq文件,可能需要跨地区传输给我们,这时候就期待能够有靠谱的压缩工具能够尽可能的减小传输文件体积,缩短传输时间;
- 传输前压缩是由一般用户操作,所以越傻瓜越好。
@superligen 确认gz数据尾部约98%的位置损坏,与gtz无关