[Users] Ploop filesystem provisioned incorrectly (wrong size)

[Kir Kolyshkin]

On 07/26/2014 08:50 PM, Kir Kolyshkin wrote:
> On 07/26/2014 12:45 PM, Kevin Holly wrote:
> > On 23/07/14 09:34, Kir Kolyshkin wrote:
> >
> > I just talked with a L3 Supporter of SolusVM and they told me that
> > this seems to be a well known vzctl bug.
>
> Great, can they point out to a bug in bugzilla.openvz.org?
>
> >
> > What SolusVM basically does is this on creation of the container:
> >
> > https://ezcrypt.it/ag9n#QcRKRX8DIFdFKJv6ZNFahTSt
>
> Thanks for providing this!
>
> Lots of weird/stupid things overall... But let's stay on topic.
>
> Here is the first relevant line:
>
> > vzctl create 134 --layout ploop --diskspace 262144000K:262144000K [...]
>
> Here they set diskspace to 250G on creation.
>
> And this is the second relevant line:
>
> > vzctl set 134 --diskspace 262144000K:262144000K --diskinodes 131072000:131072000 --save
>
> Here they resize it with 250G diskspace and 131072000 of diskinodes.
>
> Now, ext4 reserve one inode per 16KB of diskspace on filesystem creation
> (you can think of it as a heuristic that an average file is 16KB of
> size), and
> there is no way to change a number of inodes on an existing filesystem.
> Well, there is one -- you need to resize the filesystem itself.
>
> As vzctl is told that 131072000 of diskinodes are required, it resizes the
> file system to the size sufficient to hold the requested number of inodes,
> which is 131072000*16K, or 2TB. Then, as diskspace is set to 250G, vzctl
> steals the rest of the space by using an invisible hidden (empty)
> balloon file.
> So, while the internals are tricky, the result is exactly as
> requested, i.e.
> a filesystem with (about) 250 GB of diskspace, but with 131072000 inodes.
>
> Now, if I can, I'd say that the number of inodes requested is way too high
> for the given disk space, unless it's really going to be used to hold that
> high number of small (about 2K on average) files.

I would like to add that previously SolusVM was passing "unlimited" to
--diskinodes
for vzctl set, which transforms to LONG_MAX (9223372036854775807 (2^63 - 1)
on an x86_64 architecture) which is definitely way too high and resulted
in a
ploop image creation error ("size too large" or something like this).
So, it seemed
like a regression in vzctl 4.7 (compared to vzctl 4.6 which just ignored
diskinodes
value for ploop-based CTs), but is in fact a bug in SolusVM which was
uncovered
by a new vzctl feature.

Now, instead of fixing it, apparently they just changed "unlimited" to
131072000,
which is not as insane as "unlimited" but still not sane for smaller CTs
(a sane
default would be to omit diskinodes altogether)

>
> >
> > And this is the reinstallation process of the container:
> >
> > https://ezcrypt.it/cg9n#sHQJeiV7Y6bl6zyBBjS60oLN
> >
> > Where the config looks exactly like this:
> >
> > https://ezcrypt.it/dg9n#g2Ico8AknpAtJbAcxkbBQDub
>
> This adds nothing new to the picture and is in line with that
> was seen before.
>
> Now, back to "vzctl bug" that they say exist in versions newer than 4.6.1.
> This diskinodes handing for ploop was added in vzctl 4.7, before that
> diskinodes value was ignored for ploop.
>
> Hope that helps. <shameless plug> By the way, we accept donations now,
> so if you feel like
> helping us back, too, feel free:
> http://openvz.livejournal.com/48757.html </shameless plug>
>
> Kir.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20140729/19e5b9da/attachment.html>