[Users] SIMFS users

[Gena Makhomed]

On 22.07.2015 5:56, Scott Dowdle wrote:

> I've read the recipes.
> Some say you have to dedicate 1GB of RAM for every TB of storage.

"dedicate 1GB of RAM for every TB of storage"
need only if deduplication is turned on in ZFS.

But deduplication is not recommended to enable - it uses
lot of memory and work slow on current x86-64 hardware with Linux.

> To build a high performance ZFS-based fileserver you really want
> to custom design the thing with the right combination of read cache
> disks, write cache disks, etc. It has compression, encryption, dedup
>  (not sure if that is in the Linux version yet), etc.  I'm guessing
> if you just want to ZFS for local stuff (VMs, containers, server
> applications, etc) you don't have to worry as much getting
> an optimal setup as you would for a dedicated fileserver.

I have 16-core servers with 128GB RAM and 2x4TB HDD + 2x480GB SDD.

CPU power and memory allow high density of containers on one server,
but disk i/o performance is bottleneck now and disk size is hard limit.

with ploop I can't use SSD for accelerating containers disk i/o
and also "ext4 over ploop over ext4" wasting disk space as overhead.

using ZFS with enabled compression and turned on L2ARC and ZIL
I have performance boost and disk space overselling thanks to ZFS.

> I'd prefer to see BTRFS mature...

I am too, but I don't have time to wait 5-10 years before this happens.
Also, BTRFS has no L2ARC/ZIL features and can't gain performance boost.

> Please don't provide me with why ZFS is the god of filesystems. I've
> heard it all before.  If you use and like all of those features and
> ZFS works great for you... go for it... more power to you.

You probably not read entire thread before answering.
If simfs support will be removed from OpenVZ - I can't use ZFS at all.

> Regarding OpenVZ checkpoint / restore and live migration... it has
> worked well for me since it was originally released in 2007 (or was
> it 2008?).  While I've had a few kernel panics in the almost 10 years
> I've been using OpenVZ (starting with the EL4-based kernel)... I
> can't remember what year I had my last one.

But live migration code from OpenVZ kernel is not included into
mainline kernel. And OpenVZ developers need instead create CRIU.

This means what something is wrong with current live migration code?
Or how you can explain, - why live migration not in mainline kernel?

> my point is there will always be bugs... but to point at a bug report
> and give up saying that it isn't stable because of bug report x... or
> that some people have had panics at some point in history... well,
> that isn't very reflective of the overall picture. ! Nothing
> personal.  We just disagree on a few topics.  We probably agree on
> way more things though.

Yes, you are right, this is not very reflective,
but in first approximation - you can easy evaluate
complexity of code by past bugreports, also evaluating
code quality by cound of vulnerabilities is common practice,
for example, postfix scored as high code quality mail server
and sendmail/exim as low code quality mail servers
only on history of vulnerabilities in the past.

So, why I can't use the same practice for estimating
code quality and code stability of different parts of OpenVZ kernel?

OpenVZ live migration is very hard code, very hard task,
and this is potentially many places for nontrivial bugs here.

If you have access to kdumps of OpenVZ kernels -
you have estimate more precise numbers, in which
kernel crashes live migration was the cause of crash.

I have no such access, so I can use only common sense
and my experience with other open and close source software.

> Every time I upgrade vzkernel I use live migration...
> so I can have as much container uptime as possible.

As I said it before, my current hosting provider does not
allow to migrate white IP between different servers in his DC,

Also, only one container has several white IPs, all other
containers uses IP from 172.16.0.0 - 172.31.255.255 subnet,
which exists only inside OpneVZ servers - all other network
know nothing about 172.16/12 subnet and how to route IP from it.

So, even I want use live migration - I can't do it right now.
More simple way - just upgrade and reboot servers at the night,
downtime will be minimal, and servers stability will be maximal,
as the additional bonus, because I don't use live migration at all.

Yes, I can change hosting provider, but I don't want
to buy separate white IP for each container on the servers.
As you know, IPv4 addresses now is very scarce resource.

So even if hosting provider allow migrating white IP between servers
- I still can't live migrate containers between servers. Sad, but true.

More realistic way in my situation is "live migration"
with zero downtime and zero client requests lost using
http://martinfowler.com/bliki/BlueGreenDeployment.html

-- 
Best regards,
  Gena