[OpenVZ] Simfs vs Ploop

jmginer

Any provider is migrating to ploop?

Any important know issue?

Performance in Ploop is the same/better/poor than Simfs?

Some consideration to taka care in migration?

Thanks!

KuJoe

Ploop has all of the advantages over simfs except for that little problem of eating up more disk space than it uses and easily making a VPS unusable and unrecoverable under certain conditions (mostly when a server is not gracefully shutdown like a power loss, kernel panic, DOS, etc...).

The OpenVZ devs say they won't fix the corruption issue since it's not a bug so I don't plan on using ploop with hardware RAID controllers. There's also a lot of complaints of ploop VPSs taking up more disk space than required (like a VPS with a 10GB hard drive using up 16GB of disk space on the node for example).

linuxthefish

In a perfect world using ploop would be nice...

letbox

@KuJoe said:
Ploop has all of the advantages over simfs except for that little problem of eating up more disk space than it uses and easily making a VPS unusable and unrecoverable under certain conditions (mostly when a server is not gracefully shutdown like a power loss, kernel panic, DOS, etc...).

The OpenVZ devs say they won't fix the corruption issue since it's not a bug so I don't plan on using ploop with hardware RAID controllers. There's also a lot of complaints of ploop VPSs taking up more disk space than required (like a VPS with a 10GB hard drive using up 16GB of disk space on the node for example).

I believe all openVZ user began forced to use ploop!

KuJoe

key900 said: I believe all openVZ user began forced to use ploop!

Not true at all.

jmginer

For me, a important thing that is not present in Ploop is the bind mounts options. I use it to assign a second disk unit for managed VPSs to host the cpbackup files in a different physical disk.

Microlinux

KuJoe said: There's also a lot of complaints of ploop VPSs taking up more disk space than required

Where did you see those complaints? This I'm curious about.

KuJoe said: easily making a VPS unusable and unrecoverable under certain conditions (mostly when a server is not gracefully shutdown like a power loss, kernel panic, DOS, etc...).

Really, this is true of any block device in those situations.

KuJoe

@Microlinux said:

There are a few bug reports in OpenVZ's Bugzilla and some conversations on vpsBoard and WHT regarding ploop using more disk space than it should and compacting or resizing doesn't help.

As for the corruption, unlike normal hard drives where you can repair it or recover some data after reboot, ploop is 100% unrecoverable.

Darwin

Why did they chose that name? Why!?

urbandictionary.com/define.php?term=ploop

MarkTurner

In Russian it may mean something else, maybe like reliable or fast

Profforg

said: Any provider is migrating to ploop?

Any important know issue?
Performance in Ploop is the same/better/poor than Simfs?
Some consideration to taka care in migration?

I would use simfs over ploop because simfs looks much faster on my tests and it make it easy to have test containers with overusage of drive space.

MarkTurner said: In Russian it may mean something else, maybe like reliable or fast

It means nothing.. There are no such word.

MarkTurner

@Profforg - I was being facetious

Profforg

MarkTurner said: @Profforg - I was being facetious

Okay..

jmginer

Some hoster providing OVZ servers with ploop?

KuJoe

@jmginer said:
Some hoster providing OVZ servers with ploop?

All of the ones that I know of that did offer ploop have all converted back to simfs due to severe loss of client's data and outages associated with trying to fix ploop files.

edan

The dd test seems f**ked with ploop:

# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync; rm -f test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 0.91991 s, 1.2 GB/s

Very misleading.

linuxthefish

@jmginer said:
Some hoster providing OVZ servers with ploop?

GVH do on all my vps with them, and I use ploop for a single openvz container with cpanel.

Silvenga

All I know is that in the stable release of SNMP, Simfs detection is broken.

coolice

@KuJoe said:

I read the hole mentioned bug incident
https://bugzilla.openvz.org/show_bug.cgi?id=3030

It appear when data write back i used and they take several measures to prevent it.

1 Add a warning in 1.12 if using data writeback

2

* diff-ploop-update-i_size-on-preallocation
Added to 2.6.32-042stab094_2

ploop: update i_size on preallocation

The patch removes FALLOC_FL_KEEP_SIZE from the flags which direct_io module
uses to preallocate disk space. The change is harmless, but decreases the
chances of irrecoverable ploop images significantly.

https://bugzilla.openvz.org/show_bug.cgi?id=3030 

3 Not sure if the last i added but they mentioned

adding an option to ploop-fsck to fix "Data cluster xxx beyond EOF" by nullifying corrseponding slots of BAT. This will lead to lost data, of course, but it may be much better than nothing -- currently there is no way to mount such images at all. 

Umair

It's a lil old topic, but just wondering if the "disadvantages" mentioned here about Ploop have changed or situation is still the same?

I am just wondering since Ploop is better in performance. (at least per this poll)

Shoaib_A

@Umair said:
It's a lil old topic, but just wondering if the "disadvantages" mentioned here about Ploop have changed or situation is still the same?

I am just wondering since Ploop is better in performance. (at least per this poll)

Ploop is better only in terms of isolation & security it provides compared to simfs. But since you are running your own node for hosting guest VMs, you don't need this feature. Other than that the situation is same what it was at time of creation of this thread

Umair

Thanks @fametel

Umair

Can anyone here who is using OpenVZ with SolusVM share their

ve-vswap-solus.conf-sample and vz.conf

Are you using the default values or have changed something in there.
(PS. I am on simfs)

Thanks

yuri

@Umair said:
I am just wondering since Ploop is better in performance. (at least per this poll)

This is a wrong information due misunderstand by a lot of people that post without know or test the tecnologies.

The PLOOP will be always slowest because the additional layers that it adds increases the IO overhead. While the SIMFS is only a chrooted bind mount with additional quotas support, their performance is pratically the same of bare metal.

If you do any test with it and with any tools you will notice that the IOPS and IORate drops slight with PLOOP (the same happens when you use a LVM or a ZVOL).

The only performance benefit is when the PLOOP runs over a NFS, because it use a one big file instead a lot of little files over a NFS but it also increases the crashes risk a lot due the network instabilities can damage the PLOOP file and it file system. So is more beneficial to use SIMFS over NFS and make tweaks (Ex.: FSC) to increate little files performance without add more crashes risks.

@Shoaib_A said:
Ploop is better only in terms of isolation & security it provides compared to simfs. But since you are running your own node for hosting guest VMs, you don't need this feature. Other than that the situation is same what it was at time of creation of this thread

The other PLOOP benefit is the snapshot support that can help a lot the backup process, and is a great rollback tool.

@Umair said:
Can anyone here who is using OpenVZ with SolusVM share their

ve-vswap-solus.conf-sample and vz.conf

Are you using the default values or have changed something in there.
(PS. I am on simfs)

Thanks

I change the restart option to stop instead of suspend (this helps when a need to reboot all containers due some glibc like updates) and I enable all iptables functions.

dragon2611

@Silvenga said:
All I know is that in the stable release of SNMP, Simfs detection is broken.

Actually it works fine, it's the Ubuntu (possibly others?) package that it's broken in, Compiled 5.73 from source and SimFS detection is working.

KuJoe

@dragon2611 You're replying to a post from 2014. :P

dragon2611

@KuJoe said:
dragon2611 You're replying to a post from 2014. :P

Opps it was showing up, probably because of @yuri 's comment above didn't notice the original posting date.