On 2015-09-25 10:02, Timofey Titovets wrote:
I'd argue that 'general usage' should be better defined in this statement. Obviously, ZFS's ARC implementation provides better performance in a significant number of common use cases for Linux, otherwise people wouldn't be using it to the degree they are. LRU often gives abysmal performance for VM images in my experience, and virtualization is becoming a very common use case for Linux. On top of that, there are lots of applications that bypass the cache almost completely, and while that is a valid option in some cases, it shouldn't be needed most of the time.2015-09-25 16:52 GMT+03:00 Jim Salter <j...@jrs-s.net>:Pretty much bog-standard, as ZFS goes. Nothing different than what's recommended for any generic ZFS use.* set blocksize to match hardware blocksize - 4K drives get 4K blocksize, 8K drives get 8K blocksize (Samsung SSDs) * LZO compression is a win. But it's not like anything sucks without it. No real impact on performance for most use, + or -. Just saves space. * > 4GB allocated to the ARC. General rule of thumb: half the RAM belongs to the host (which is mostly ARC), half belongs to the guests. I strongly prefer pool-of-mirrors topology, but nothing crazy happens if you use striped-with-parity instead. I use to use RAIDZ1 (the rough equivalent of RAID5) quite frequently, and there wasn't anything amazingly sucky about it; it performed at least as well as you'd expect ext4 on mdraid5 to perform. ZFS might or might not do a better job of managing fragmentation; I really don't know. I strongly suspect the design difference between the kernel's simple FIFO page cache and ZFS' weighted cache makes a really, really big difference. On 09/25/2015 09:04 AM, Austin S Hemmelgarn wrote:you really need to give specifics on how you have ZFS set up in that case.-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlFYI: Linux pagecache use LRU cache algo, and in general case it's working good enough
If it's just plain LRU, I may take the time at some point to try and write some patches to test if SLRU works any better (as SLRU is essentially ARC without the auto-tuning), although I have nowhere near the resources to test something like that to the degree that would be required to get it even considered for inclusion in mainline.
smime.p7s
Description: S/MIME Cryptographic Signature
