Re: compressor
Le vendredi 24 août 2012 à 13:28 -0600, Bob Proulx a écrit : > You are very observant! And by this you are not in the target > audience I was talking about. I know people and many people will see > 66M versus 65M as a strong indicator when it should not be taken as > significant at all. These people would see 0.001% as being > different, strictly one is measured at larger than the other, and make > a conclusion which they should not conclude. That you observe this > correctly shows that you are smarter than these other people that I > worry about. :-) Seems not: I did not understand the true meaning of your remark. I've just reread it and it seems I skipped half of it. The 1MB/s internet connection speed was just an order of magnitude. I hope you are not struggling with a 56k modem :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345920221.9884.13.ca...@p76-nom-gd.cnrs-imn.fr
Re: compressor
Gaël DONVAL wrote: > Bob Proulx a écrit : > > There is a problem with the mashing and reformatting. It makes lzip > > appear to be 66M against xz being 65M and so xz is better, right? But > > wait the above says that gz is 99M. But ls says 100M. So the listed > > sizes are not 100% correct. So 66M is true if 100M is true. But it > > seems that something was truncating down to 99M and so perhaps that > > 65M is actually 66M? In which case xz and lz were actually the same > > for that sample. Or perhaps if they count 65M as true for xy then > > perhaps it should be 65M for lz too? > > > > I think you see the problem. I don't really know from the above data > > whether xz or lz is the same or worse or better. > > ... > Even if you are perfectly right, I wouldn't look at the long byte count. > A MB today is downloaded in 1s with most internet connection and if you You have a faster network connection than I do. Or rather I do not have as fast of a connection as "most people" do these days. :-) In my case I would like something faster but in my area while this is possible it is many times more expensive. I must wait. > take linux-2.6 archive or your whole / partition archive, you might see > that lz/xz performs worse/better that xz/lz considering file size. Agreed. > From my point of view, I see two programs performing almost equally well > on a big bunch of ascii files on this hardware. You are very observant! And by this you are not in the target audience I was talking about. I know people and many people will see 66M versus 65M as a strong indicator when it should not be taken as significant at all. These people would see 0.001% as being different, strictly one is measured at larger than the other, and make a conclusion which they should not conclude. That you observe this correctly shows that you are smarter than these other people that I worry about. :-) > So the next question would be "which one is faster?" and even before > that, I would wonder "Are these programs available on my cluster?" > > But once again you are perfectly right to ask for more precision, I just > say that there are high chances that you won't be able to conclude > anything. Agreed. My comment was directed toward the human element. :-) Bob signature.asc Description: Digital signature
Re: compressor
Le vendredi 24 août 2012 à 10:10 +0100, Jon Dowland a écrit : > > Most compressors work on a block-cipher model in order to support stream > operation and so the compressor doesn't have a global view of the data being > compressed. At least with 7zip and xz, you can tweak the block size directly and at least LZMA, Deflate, PPMd are able to do multiple pass. > That's why subsequent manual passes can (sometimes) have a good > effect, especially with e.g. enormous log files with a lot of repetition: > local > areas of the file being compressed are treated in isolation, but the resulting > compressed blocks have a lot of (compressed!) repetition. In practise it's > almost certainly very rarely worth bothering. That makes sense. AFAIK, you can't manually set the block size with gzip which is a shame for non-streamed files. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345800669.4875.24.ca...@p76-nom-gd.cnrs-imn.fr
Re: compressor
Le jeudi 23 août 2012 à 14:26 -0600, Bob Proulx a écrit : > Jon Dowland wrote: > > Bob Proulx wrote: > > > Jon Dowland wrote: > > > > linux-3.6-rc2.tar.bz2 78M > > > > linux-3.6-rc2.tar.gz 99M > > > > linux-3.6-rc2.tar.xz 65M > > > linux-3.6-rc2.tar.lz 66M > > > > > > I think lzip is worthy enough that it should have a mention too. It > > > has gotten less attention than xz and that is sad since it is a nice > > > free software tool. I recompressed that file using lzip for this > > > comparison. > > > > Thanks for the data (mashed/reformatted into quote above). I copied the > > listings from the kernel.org archives, so the choice of compression types > > was theirs (although I hadn't heard of lzip, thanks!) > > There is a problem with the mashing and reformatting. It makes lzip > appear to be 66M against xz being 65M and so xz is better, right? But > wait the above says that gz is 99M. But ls says 100M. So the listed > sizes are not 100% correct. So 66M is true if 100M is true. But it > seems that something was truncating down to 99M and so perhaps that > 65M is actually 66M? In which case xz and lz were actually the same > for that sample. Or perhaps if they count 65M as true for xy then > perhaps it should be 65M for lz too? > > I think you see the problem. I don't really know from the above data > whether xz or lz is the same or worse or better. > > I didn't go and download the linux-3.6-rc2.tar.xz file to see what > size it actually should be listed as. I probably should have. But I > didn't have the time. > > It would be better to look at the long byte counts for this type of > comparison. > > Bob Even if you are perfectly right, I wouldn't look at the long byte count. A MB today is downloaded in 1s with most internet connection and if you take linux-2.6 archive or your whole / partition archive, you might see that lz/xz performs worse/better that xz/lz considering file size. >From my point of view, I see two programs performing almost equally well on a big bunch of ascii files on this hardware. So the next question would be "which one is faster?" and even before that, I would wonder "Are these programs available on my cluster?" But once again you are perfectly right to ask for more precision, I just say that there are high chances that you won't be able to conclude anything. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345799759.4875.13.ca...@p76-nom-gd.cnrs-imn.fr
Re: compressor
On Thu, Aug 23, 2012 at 02:26:25PM -0600, Bob Proulx wrote: > There is a problem with the mashing and reformatting. It makes lzip > appear to be 66M against xz being 65M and so xz is better, right? snip > It would be better to look at the long byte counts for this type of > comparison. You're right, that would be necessary to be accurate. An exercise left for another reader! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120824091145.GF19780@debian
Re: compressor
On Fri, Aug 24, 2012 at 11:04:56AM +0200, Gaël DONVAL wrote: > Le jeudi 23 août 2012 à 20:24 +0800, lina a écrit : > > > > Sorry, here you mean, > > > > once tar -Jcf a.tar.xz a > > > > again > > tar -Jcf a.tar.xz a.tar.xz > > ? > No, I think this was a joke :) Yes it was a joke :) but it was based on a recent article where someone expressed surprise that multiple manual passes of a compressor (I think gz) resulted in smaller file sizes. (I couldn't find a copy of the article to link to) > In most programs, there is a "depth" or "pass number" parameter that > does just this already. If you try to compress again, the overhead > induced by the container (headers and such) will ultimately increase the > file size. Most compressors work on a block-cipher model in order to support stream operation and so the compressor doesn't have a global view of the data being compressed. That's why subsequent manual passes can (sometimes) have a good effect, especially with e.g. enormous log files with a lot of repetition: local areas of the file being compressed are treated in isolation, but the resulting compressed blocks have a lot of (compressed!) repetition. In practise it's almost certainly very rarely worth bothering. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120824091035.GE19780@debian
Re: compressor
Le jeudi 23 août 2012 à 20:24 +0800, lina a écrit : > > Sorry, here you mean, > > once tar -Jcf a.tar.xz a > > again > tar -Jcf a.tar.xz a.tar.xz > ? No, I think this was a joke :) In most programs, there is a "depth" or "pass number" parameter that does just this already. If you try to compress again, the overhead induced by the container (headers and such) will ultimately increase the file size. Oh, BTW, if you don't need file permissions, just use 7zip directly on the directories you want to compress: you will avoid tar format overhead. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345799096.4875.5.ca...@p76-nom-gd.cnrs-imn.fr
Re: compressor
Jon Dowland wrote: > Bob Proulx wrote: > > Jon Dowland wrote: > > > linux-3.6-rc2.tar.bz2 78M > > > linux-3.6-rc2.tar.gz 99M > > > linux-3.6-rc2.tar.xz 65M > > linux-3.6-rc2.tar.lz 66M > > > > I think lzip is worthy enough that it should have a mention too. It > > has gotten less attention than xz and that is sad since it is a nice > > free software tool. I recompressed that file using lzip for this > > comparison. > > Thanks for the data (mashed/reformatted into quote above). I copied the > listings from the kernel.org archives, so the choice of compression types > was theirs (although I hadn't heard of lzip, thanks!) There is a problem with the mashing and reformatting. It makes lzip appear to be 66M against xz being 65M and so xz is better, right? But wait the above says that gz is 99M. But ls says 100M. So the listed sizes are not 100% correct. So 66M is true if 100M is true. But it seems that something was truncating down to 99M and so perhaps that 65M is actually 66M? In which case xz and lz were actually the same for that sample. Or perhaps if they count 65M as true for xy then perhaps it should be 65M for lz too? I think you see the problem. I don't really know from the above data whether xz or lz is the same or worse or better. I didn't go and download the linux-3.6-rc2.tar.xz file to see what size it actually should be listed as. I probably should have. But I didn't have the time. It would be better to look at the long byte counts for this type of comparison. Bob signature.asc Description: Digital signature
Re: compressor
On Thursday 23,August,2012 06:26 PM, Jon Dowland wrote: > On Wed, Aug 22, 2012 at 03:43:24PM +, Camaleón wrote: >> On Wed, 22 Aug 2012 21:40:36 +0800, lina wrote: >> >>> Basically which compressor is the most efficient one. >> >> Ha, that's like asking "what do clouds smell like"? >:-) > > Remember to run your chosen compression algorithm at least twice! Sorry, here you mean, once tar -Jcf a.tar.xz a again tar -Jcf a.tar.xz a.tar.xz ? > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50362116.5010...@gmail.com
Re: compressor
On Wed, Aug 22, 2012 at 03:43:24PM +, Camaleón wrote: > On Wed, 22 Aug 2012 21:40:36 +0800, lina wrote: > > > Basically which compressor is the most efficient one. > > Ha, that's like asking "what do clouds smell like"? >:-) Remember to run your chosen compression algorithm at least twice! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823102607.GJ10344@debian
Re: compressor
On Wed, Aug 22, 2012 at 04:44:38PM -0600, Bob Proulx wrote: > Jon Dowland wrote: > > linux-3.6-rc2.tar.bz2 78M > > linux-3.6-rc2.tar.gz 99M > > linux-3.6-rc2.tar.xz 65M > linux-3.6-rc2.tar.lz 66M > > I think lzip is worthy enough that it should have a mention too. It > has gotten less attention than xz and that is sad since it is a nice > free software tool. I recompressed that file using lzip for this > comparison. Thanks for the data (mashed/reformatted into quote above). I copied the listings from the kernel.org archives, so the choice of compression types was theirs (although I hadn't heard of lzip, thanks!) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120823102436.GI10344@debian
Re: compressor
Le mercredi 22 août 2012 à 12:52 -0400, Gary Dale a écrit : > I find that .lzma does a pretty good job and isn't too slow. My 2 cents: LZMA/LZMA2 is indeed a good choice if you want best compression: it should work with almost anything (except already compressed streams such as videos, images, sounds, obviously). For text files however, you could try the PPMd algorithm which performs equally well as LZMA but for a fraction of memory/time LZMA uses. But it sucks for almost everything else than text. A warning: xz -9e might increase a LOT the compression time for almost NO size reduction compared to the defaults. Also keep in mind that the compression algorithm uses more memory when the compression level increases: for big datasets, you will run out of memory if you are too greedy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345713219.4552.8.ca...@p76-nom-gd.cnrs-imn.fr
Re: compressor
Jon Dowland wrote: > Ralf Mardorf wrote: > > Jerome BENOIT wrote: > > > xz: tar Jcf > > > > I'm using a distro that packages with xz. > > > > I'm sure that there never was a big difference between > > "gz: tar zcf" and "bzip2: tar jcf" for the length of the files, but the > > time for packing and unpacking does differ very much. > > Indeed, bz2 is very slow. But it can be much better at compressing: > > linux-3.6-rc2.tar.bz2 16-Aug-2012 22:01 78M > linux-3.6-rc2.tar.gz 16-Aug-2012 22:01 99M > linux-3.6-rc2.tar.xz 16-Aug-2012 22:01 65M I think lzip is worthy enough that it should have a mention too. It has gotten less attention than xz and that is sad since it is a nice free software tool. I recompressed that file using lzip for this comparison. $ ls -lhog linux-3.6-rc2.tar.gz -rw-rw-r-- 1 100M Aug 22 15:31 linux-3.6-rc2.tar.gz $ ls -lhog linux-3.6-rc2.tar.lz -rw-rw-r-- 1 66M Aug 22 15:54 linux-3.6-rc2.tar.lz Bob signature.asc Description: Digital signature
Re: compressor
On 22/08/12 12:12 PM, lina wrote: On Wednesday 22,August,2012 11:43 PM, Camaleón wrote: On Wed, 22 Aug 2012 21:40:36 +0800, lina wrote: Basically which compressor is the most efficient one. Ha, that's like asking "what do clouds smell like"?>:-) I got 2T data, basically won't get a chance to use in future, but still need to keep there at least for the next two years just in case. so I tried the xz, but xz not support the directory? or maybe I don't know how to compress the directory. This may help: http://unix.stackexchange.com/questions/28976/how-to-xz-a-directory-with-tar-using-maximum-compression now tried the .bz2, but still very large. For my usual data backup I use tar and bz2 though I don't expect to compress too much but I need the best interop and compatibility. Anyway, what kind of data is that heap of 2 TiB? Thanks. those data files accumulated there for 2 years, today just do the clear up. Multimedia binary files (image, video, audio...) use their own compression algorithms so you are not going to get any noticeable gain when compressing these kind of files. For general purpose data compression, Wikipedia has a good list: http://en.wikipedia.org/wiki/Comparison_of_file_archivers And also some info on benchmarks: http://en.wikipedia.org/wiki/Lossless_compression_benchmarks#Lossless_compression_benchmarks Thanks again for those links. Warm regards, Greetings, I find that .lzma does a pretty good job and isn't too slow. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50350e3d.1030...@rogers.com
Re: compressor
On Wednesday 22,August,2012 11:43 PM, Camaleón wrote: > On Wed, 22 Aug 2012 21:40:36 +0800, lina wrote: > >> Basically which compressor is the most efficient one. > > Ha, that's like asking "what do clouds smell like"? >:-) > >> I got 2T data, basically won't get a chance to use in future, but still >> need to keep there at least for the next two years just in case. >> >> so I tried the xz, but xz not support the directory? or maybe I don't >> know how to compress the directory. > > This may help: > > http://unix.stackexchange.com/questions/28976/how-to-xz-a-directory-with-tar-using-maximum-compression > >> now tried the .bz2, but still very large. > > For my usual data backup I use tar and bz2 though I don't expect to compress > too much but I need the best interop and compatibility. > > Anyway, what kind of data is that heap of 2 TiB? Thanks. those data files accumulated there for 2 years, today just do the clear up. > > Multimedia binary files (image, video, audio...) use their own > compression algorithms so you are not going to get any noticeable gain > when compressing these kind of files. > > For general purpose data compression, Wikipedia has a good list: > > http://en.wikipedia.org/wiki/Comparison_of_file_archivers > > And also some info on benchmarks: > > http://en.wikipedia.org/wiki/Lossless_compression_benchmarks#Lossless_compression_benchmarks > Thanks again for those links. Warm regards, > Greetings, > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503504fd.9010...@gmail.com
Re: compressor
On Wed, 22 Aug 2012 21:40:36 +0800, lina wrote: > Basically which compressor is the most efficient one. Ha, that's like asking "what do clouds smell like"? >:-) > I got 2T data, basically won't get a chance to use in future, but still > need to keep there at least for the next two years just in case. > > so I tried the xz, but xz not support the directory? or maybe I don't > know how to compress the directory. This may help: http://unix.stackexchange.com/questions/28976/how-to-xz-a-directory-with-tar-using-maximum-compression > now tried the .bz2, but still very large. For my usual data backup I use tar and bz2 though I don't expect to compress too much but I need the best interop and compatibility. Anyway, what kind of data is that heap of 2 TiB? Multimedia binary files (image, video, audio...) use their own compression algorithms so you are not going to get any noticeable gain when compressing these kind of files. For general purpose data compression, Wikipedia has a good list: http://en.wikipedia.org/wiki/Comparison_of_file_archivers And also some info on benchmarks: http://en.wikipedia.org/wiki/Lossless_compression_benchmarks#Lossless_compression_benchmarks Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k12ums$6m0$1...@ger.gmane.org
Re: compressor
On Wednesday 22,August,2012 10:50 PM, Jon Dowland wrote: > On Wed, Aug 22, 2012 at 04:24:19PM +0200, Ralf Mardorf wrote: >> On Wed, 2012-08-22 at 16:15 +0200, Jerome BENOIT wrote: >>> xz: tar Jcf $ tar --version tar (GNU tar) 1.14 no -J options. On desktop it's tar (GNU tar) 1.26 can support the .tar.xz Thanks, >> >> I'm using a distro that packages with xz. >> >> I'm sure that there never was a big difference between >> "gz: tar zcf" and "bzip2: tar jcf" for the length of the files, but the >> time for packing and unpacking does differ very much. > > Indeed, bz2 is very slow. But it can be much better at compressing: > > linux-3.6-rc2.tar.bz2 16-Aug-2012 22:01 78M > linux-3.6-rc2.tar.gz 16-Aug-2012 22:01 99M > linux-3.6-rc2.tar.xz 16-Aug-2012 22:01 65M > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034f30e.6080...@gmail.com
Re: compressor
On Wed, Aug 22, 2012 at 04:24:19PM +0200, Ralf Mardorf wrote: > On Wed, 2012-08-22 at 16:15 +0200, Jerome BENOIT wrote: > > xz: tar Jcf > > I'm using a distro that packages with xz. > > I'm sure that there never was a big difference between > "gz: tar zcf" and "bzip2: tar jcf" for the length of the files, but the > time for packing and unpacking does differ very much. Indeed, bz2 is very slow. But it can be much better at compressing: linux-3.6-rc2.tar.bz2 16-Aug-2012 22:01 78M linux-3.6-rc2.tar.gz 16-Aug-2012 22:01 99M linux-3.6-rc2.tar.xz 16-Aug-2012 22:01 65M -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120822145052.GE10344@debian
Re: compressor
On 22/08/12 16:24, Ralf Mardorf wrote: On Wed, 2012-08-22 at 16:15 +0200, Jerome BENOIT wrote: xz: tar Jcf I'm using a distro that packages with xz. I'm sure that there never was a big difference between "gz: tar zcf" and "bzip2: tar jcf" for the length of the files, that higly depends on the nature of the files: if the files are compressed file, teh difference is zero; otherwise `xz -9e' is most of the time better. but the time for packing and unpacking does differ very much. bzip2 compression is a good compromised between speed and size. xz compresses slowly, but decompress fastly. Other criteria can enter into account: if rsync is used, tricks may be applied. Jerome Speaking for Linux backups and audio data backups. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034edb0.6060...@rezozer.net
Re: compressor
On Wed, 2012-08-22 at 16:15 +0200, Jerome BENOIT wrote: > xz: tar Jcf I'm using a distro that packages with xz. I'm sure that there never was a big difference between "gz: tar zcf" and "bzip2: tar jcf" for the length of the files, but the time for packing and unpacking does differ very much. Speaking for Linux backups and audio data backups. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345645459.3957.139.camel@precise
Re: compressor
On Wednesday 22,August,2012 10:15 PM, Jerome BENOIT wrote: > gz: tar zcf > bzip2: tar jcf > xz: tar Jcf > So the most efficient one is the .tar.xz one? > > On 22/08/12 16:07, Ralf Mardorf wrote: >> PPS: For my needs "tar czf" aka ".tar.gz" is the best way to go. More >> compression doesn't lead to smaller files, but it takes much more time. >> >> > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034eaf3.70...@gmail.com
Re: compressor
On Wednesday 22,August,2012 09:54 PM, Ralf Mardorf wrote: > On Wed, 2012-08-22 at 21:40 +0800, lina wrote: >> Hi, >> >> Basically which compressor is the most efficient one. >> >> I got 2T data, basically won't get a chance to use in future, but still >> need to keep there at least for the next two years just in case. >> >> so I tried the xz, but xz not support the directory? or maybe I don't >> know how to compress the directory. >> >> now tried the .bz2, but still very large. >> >> Thanks ahead for any suggestions, >> >> Best regards, > > AFAIK 7z does best compression, but IIRC without keeping Linux > permissions. Thanks. > > Regards, > Ralf > > PS: "Compressor" is an audio engineering term too :D. So the other > answer is "Jamin", not helpful regarding to the context. P.P.S. I noticed the discussion in another threads, about funny and misbehavior and etc. I must confess here that I am not the very loyal reader of those emails, but here I just wanna say one thing or two, in the past, some witty conversation/jokes really made, I think, not merely my days, but also many other people's days, I laughed even I didn't say anything at that time and I think the funny things definitely bring some special flavors to the list. Thanks with best regards, > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034e9f0.80...@gmail.com
Re: compressor
gz: tar zcf bzip2: tar jcf xz: tar Jcf On 22/08/12 16:07, Ralf Mardorf wrote: PPS: For my needs "tar czf" aka ".tar.gz" is the best way to go. More compression doesn't lead to smaller files, but it takes much more time. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034e994.50...@rezozer.net
Re: compressor
PPS: For my needs "tar czf" aka ".tar.gz" is the best way to go. More compression doesn't lead to smaller files, but it takes much more time. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/134567.3957.134.camel@precise
Re: compressor
On Wed, 2012-08-22 at 15:54 +0200, Ralf Mardorf wrote: > On Wed, 2012-08-22 at 21:40 +0800, lina wrote: > > Hi, > > > > Basically which compressor is the most efficient one. > > > > I got 2T data, basically won't get a chance to use in future, but still > > need to keep there at least for the next two years just in case. > > > > so I tried the xz, but xz not support the directory? or maybe I don't > > know how to compress the directory. > > > > now tried the .bz2, but still very large. > > > > Thanks ahead for any suggestions, > > > > Best regards, > > AFAIK 7z does best compression, but IIRC without keeping Linux > permissions. > > Regards, > Ralf > > PS: "Compressor" is an audio engineering term too :D. So the other > answer is "Jamin", not helpful regarding to the context. PS: Regarding to bz, test if more compression really does safe space, or if it just needs much more time, but needs nearly the same space. Regarding to this, I experienced another "less is more" issue. Regarding to the kind of data you'll archive it might differ for your needs. You need to test all possibilities, AFAIK here are no rules of thumb. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345644016.3957.131.camel@precise
Re: compressor
On Wed, 2012-08-22 at 21:40 +0800, lina wrote: > Hi, > > Basically which compressor is the most efficient one. > > I got 2T data, basically won't get a chance to use in future, but still > need to keep there at least for the next two years just in case. > > so I tried the xz, but xz not support the directory? or maybe I don't > know how to compress the directory. > > now tried the .bz2, but still very large. > > Thanks ahead for any suggestions, > > Best regards, AFAIK 7z does best compression, but IIRC without keeping Linux permissions. Regards, Ralf PS: "Compressor" is an audio engineering term too :D. So the other answer is "Jamin", not helpful regarding to the context. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345643698.3957.126.camel@precise
compressor
Hi, Basically which compressor is the most efficient one. I got 2T data, basically won't get a chance to use in future, but still need to keep there at least for the next two years just in case. so I tried the xz, but xz not support the directory? or maybe I don't know how to compress the directory. now tried the .bz2, but still very large. Thanks ahead for any suggestions, Best regards, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034e154.5000...@gmail.com
