Re: [zfs-discuss] zfs on SunFire X2100M2 with hybrid pools
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Jim Klimov I really hope someone better versed in compression - like Saso - would chime in to say whether gzip-9 vs. lzjb (or lz4) sucks in terms of read-speeds from the pools. My HDD-based assumption is in general that the less data you read (or write) on platters - the better, and the spare CPU cycles can usually take the hit. Oh, I can definitely field that one - The lzjb compression (default compression as long as you just turn compression on without specifying any other detail) is very fast compression, similar to lzo. It generally has no noticeable CPU overhead, but it saves you a lot of time and space for highly repetitive things like text files (source code) and sparse zero-filled files and stuff like that. I personally always enable this. compresson=on zlib (gzip) is more powerful, but *way* slower. Even the fastest level gzip-1 uses enough CPU cycles that you probably will be CPU limited rather than IO limited. There are very few situations where this option is better than the default lzjb. Some data (anything that's already compressed, zip, gz, etc, video files, jpg's, encrypted files, etc) are totally uncompressible with these algorithms. If this is the type of data you store, you should not use compression. Probably not worth mention, but what the heck. If you normally have uncompressible data and then one day you're going to do a lot of stuff that's compressible... (Or vice versa)... The compression flag is only used during writes. Once it's written to the pool, compressed or uncompressed, it stays that way, even if you change the flag later. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Question about degraded drive
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Freddie Cash And you can try 'zpool online' on the failed drive to see if it comes back online. Be cautious here - I have an anecdote, which might represent a trend in best practice, or it might just be an anecdote. At least once, I had an iscsi device go offline, and then I zpool onlined the device, and it seemed to work - resilvered successfully, zpool status showed clean, I'm able to zfs send and zfs receive. But for normal usage (go in and actually use the files in the pool) it was never usable again. I don't know the root cause right now. Maybe it's iscsi related. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs on SunFire X2100M2 with hybrid pools
Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Jim Klimov I really hope someone better versed in compression - like Saso - would chime in to say whether gzip-9 vs. lzjb (or lz4) sucks in terms of read-speeds from the pools. My HDD-based assumption is in general that the less data you read (or write) on platters - the better, and the spare CPU cycles can usually take the hit. Oh, I can definitely field that one - The lzjb compression (default compression as long as you just turn compression on without specifying any other detail) is very fast compression, similar to lzo. It generally has no noticeable CPU overhead, but it saves you a lot of time and space for highly repetitive things like text files (source code) and sparse zero-filled files and stuff like that. I personally always enable this. compresson=on zlib (gzip) is more powerful, but *way* slower. Even the fastest level gzip-1 uses enough CPU cycles that you probably will be CPU limited rather than IO limited. I haven't seen that for a long time. When gzip compression was first introduced, it would cause writes on a Thumper to be CPU bound. It was all but unusable on that machine. Today with better threading, I barely notice the overhead on the same box. There are very few situations where this option is better than the default lzjb. That part I do agree with! -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs on SunFire X2100M2 with hybrid pools
Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote: There are very few situations where (gzip) option is better than the default lzjb. Well, for the most part my question regarded the slowness (or lack of) gzip DEcompression as compared to lz* algorithms. If there are files and data like the OS (LZ/GZ) image and program binaries, which are written once but read many times, I don't really care how expensive it is to write less data (and for an OI installation the difference between lzjb and gzip-9 compression of /usr can be around or over 100Mb's) - as long as I keep less data on-disk and have less IOs to read in the OS during boot and work. Especially so, if - and this is the part I am not certain about - it is roughly as cheap to READ the gzip-9 datasets as it is to read lzjb (in terms of CPU decompression). //Jim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Question about degraded drive
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Chris Dunbar - Earthside, LLC # zpool replace tank c11t4d0 # zpool clear tank I would expect this to work, or detach/attach. You should scrub periodically, and ensure no errors after scrub. But the really good question is why does the device go offline? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
