[ensembl-dev] Bad data in MySQL dumps

[njohnson at ebi.ac.uk]

Hi Fedor

The error would seem to be correct, the rough footprint for this table for
v61 was 193GB. This is web optimised data, designed to speed up the wiggle
track displays.  For v62 this has been moved outside of the database for
various reasons, there will be a blog post about this shortly.

wrt the gunzip -l output, that does seem a little odd. I will see if I can
recreate.

Nath

> Basically, it says:
>   gzip: result_feature.txt: No space left on device
> And i have >100Gb left on this partition.
>
> gunzip -l reports this:
>         compressed        uncompressed  ratio uncompressed_name
>         11304575360          1712567965 -560.1% result_feature.txt
> Seems kinda weird.
>
>
> On Fri, Apr 8, 2011 at 4:42 PM, Nathan Johnson <njohnson at ebi.ac.uk> wrote:
>> Hi Fedor
>>
>> Can you be more specific when you say 'fails to unpack'? What happens
>> exactly?
>>
>> I suspect what you are seeing is that it is taking a long time to unpack
>> as these files are particularly large. Â Also, please see the README
>> file for more information on how to handle the result_feature imports,
>> as they require some non-standard parameters to handle the BLOB data.
>>
>> Thanks
>>
>>
>> Nath
>>
>> On 3 Apr 2011, at 12:14, Fedor Gusev wrote:
>>
>>> Hello everyone.
>>>
>>> I have some problems with file
>>> Â ftp://ftp.ensembl.org/pub/release-61/mysql/homo_sapiens_funcgen_61_37f/result_feature.txt.gz
>>>
>>> It is not present in CHECKSUMS file and fails to unpack. Can you
>>> please check on this?
>>>
>>> --
>>> Kind regards,
>>> Fedor Gusev.
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at ensembl.org
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>
>> Nathan Johnson
>> Senior Scientific Programmer
>> Ensembl Regulation
>> European Bioinformatics Institute
>> Wellcome Trust Genome Campus
>> Hinxton
>> Cambridge CB10 1SD
>>
>> http://www.ensembl.info/
>> http://twitter.com/#!/ensembl
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Kind regards,
> Fedor Gusev.
>