Re: BTRFS as image store for KVM?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

On 2015-09-25 10:02, Timofey Titovets wrote:
> 2015-09-25 16:52 GMT+03:00 Jim Salter <jim@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> FYI:
> Linux pagecache use LRU cache algo, and in general case it's working good enough
>
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.

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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]