On 07/24/2015 05:57 PM, Gena Makhomed wrote:
On 25.07.2015 1:06, Kir Kolyshkin wrote: what I am doing wrong, and
how I can decrease ploop overhead here?
Most probably it's because of filesystem defragmentation (my item #2
above).
We are currently working on that. For example, see this report:
https://lwn.net/Articles/637428/
This defragmentation tool can be used in case "XFS over ploop over XFS"
for defragmenting both filesystems - inside ploop container and at HN ?
There is no need to defragment the "outer" fs.
Or defragmentation will be used only inside ploop
to align internal filesystem to ploop 1MiB chunks?
This tool is to be used for inner ploop ext4. As a result, the data will
be less sparse,
there will be more empty blocks for ploop to discard.
I encourage you to experiment with e4defrag2 and post your results here.
Usage is something like this (assuming default ploop cluster size of 1M, and
you have /dev/ploop12345p1 mounted on /vz/root/123):
e4defrag2 -v -d 255 -m -s 8 -q 999 \
-a $((64*1024)) \
-c $((1024*1024 * 1)) \
-t $((60*10)) \
/dev/ploop12345p1 /vz/root/123
Try to run vzctl compact before and after, check if defrag helps. You
might want to drop -a option,
or increase argument of -t option. Note I am not the utility author and
can hardly help much.
Also, you might try to play with ploop cluster block size. Default is
1M, maybe you'll
have better luck with smaller block size (although it was never tested
with blocks less
than 1M). Block size (in sectors, default is 2048 i.e. 2048 * 512 = 1M)
can be specified
with ploop init -b option.
What else is there in ploop? As far as I know, a partition table, and an
ext4 journal with
a fixed size of 128MB (its overhead is only major if you create pretty
small ploop images).
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
