1/17/2024 0 Comments Tar compress os xAs the memory buffer fills up, it will pipe that data, in memory, through to the tar file format parser, which will read the information about metadata, etc.READ the 1 GB compressed data contents of, a block at a time, into memory.The total data we WROTE to disk in this process was 2 GB (for gunzip) + 2 GB (for tar) + a few bytes for metadata = about 4 GB. The total data we READ from disk in this process was 1 GB (for gunzip) + 2 GB (for tar) = 3 GB. This involves: translating the data structure / metadata information into creating new files and directories on disk as appropriate, or rewriting existing files and directories with new data contents. WRITE the 2 GB of data plus the metadata to disk.READ the 2 GB of uncompressed data contents of blah.tar and the tar file format's data structures, including information about file permissions, file names, directories, etc.The file size is probably a couple of bytes larger than the sum of all the file data would be. Now, you have blah.tar on disk, which is uncompressed but contains one or more files within it, with very low data structure overhead. As the memory buffer fills up with "a block" worth of data, WRITE the uncompressed data into the file blah.tar on disk and repeat until all the compressed data is read.PROCESS the compressed data through the gzip decompressor in memory.READ the 1 GB compressed data contents of. This would read the contents of blah.tar from disk, compress them through the gzip compression algorithm, write the contents to, then unlink (delete) the file blah.tar. This would result in blah.tar which is a mere aggregation of the files. The way that you would create this, if you were to do archiving and compression separately, would be: tar cf blah.tar files. You have a file on disk which is, say, 1 GB of gzip-compressed data which, when uncompressed, occupies 2 GB (so a compression ratio of 50%). Here is a comparison of two separate workflows and what they do. Since tar is such an old file format, and newer file formats exist today, why is tar (whether encapsulated in gzip, bzip2 or even the new xz) still so widely used today on GNU/Linux, Android, BSD, and other such UNIX operating systems, for file transfers, program source and binary downloads, and sometimes even as a package manager format? gzip and Deflate are similar).Īre there features of the tar file format that other file formats, such as. Is there a performance penalty during the aggregation/compression/decompression stages for using tar encapsulated in gzip or bzip2, when compared to using a file format that does aggregation and compression in the same data structure? Assume the runtime of the compressor being compared is identical (e.g. I know that tar was made for tape archives back in the day, but today we have archive file formats that both aggregate files and perform compression within the same logical file format. Answers without enough detail may be edited or deleted. Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |