[Users] simfs with ploop?

Rene C. openvz at dokbua.com
Wed Jan 21 09:08:11 PST 2015 

QUOTAUGIDLIMIT is set to 3000 in the containers where it is set at all.  It
doesn't seem to have any bearing on the problem though -  some containers
with this problem have QUOTAUGIDLIMIT set, others don't.

2201 probably doesn't have second -level quota, 2202 does - and has a
number of /dev/ploop* devices, but /proc/mounts doesn't list the correct
one.

On Wed, Jan 21, 2015 at 5:51 PM, Kir Kolyshkin <kir at openvz.org> wrote:

>
> On 01/21/2015 08:27 AM, Rene C. wrote:
>
> The reason I became aware of the problem was that a cpanel servers started
> sending this message every morning:
>
>  repquota: Can't stat() mounted device /dev/ploop50951p1: No such file or
> directory
>
>  All containers on another hardware node and several on this have the
> devices working correctly within the containers.
>
>
> What's the setting of QUOTAUGIDLIMIT for a given container?
> Note ploop device is only created inside the container if second-level
> quota is enabled.
>
>
> On Wed, Jan 21, 2015 at 5:11 PM, Devon B. <devon.b at virtualcomplete.com>
> wrote:
>
>> I can't speak as to how to address the issue, but why do you consider it
>> messed up?  I logged in to a few nodes and saw the same thing on all of
>> them and I don't remember this being any different in the past.  The ploop
>> device only exists outside of the container (when mounted).  Inside the
>> container is just a reference, no actual device exists.
>>
>> I don't know enough about the original issue, what are you trying to
>> accomplish with the ploop device inside the container?
>>
>>
>>    Rene C. <openvz at dokbua.com>
>>  Wednesday, January 21, 2015 6:47 AM
>>   I've gone through all containers and actually some of them work
>> correctly, only some are messed up like this.
>>
>>  Take for example this one:
>>
>>  [root at server22 ~]# vzctl restart 2201
>> Restarting container
>> Stopping container ...
>> Container was stopped
>> Unmounting file system at /vz/root/2201
>> Unmounting device /dev/ploop27939
>> Container is unmounted
>> Starting container...
>> Opening delta /vz/private/2201/root.hdd/root.hdd
>> Adding delta dev=/dev/ploop27939 img=/vz/private/2201/root.hdd/root.hdd
>> (ro)
>> Adding delta dev=/dev/ploop27939
>> img=/vz/private/2201/root.hdd/root.hdd.{7a09b730-f2d6-4b21-b856-0bd6ca420a6e}
>> (rw)
>> Mounting /dev/ploop27939p1 at /vz/root/2201 fstype=ext4
>> data='balloon_ino=12,'
>> Container is mounted
>> Adding IP address(es): (redacted)
>> Setting CPU limit: 400
>> Setting CPU units: 50
>> Setting CPUs: 4
>> Container start in progress...
>>
>>  So apparently the ploop device should be /dev/ploop/27939. Everything
>> seems to work, inside the container this device is referred by /proc/mounts
>>
>>  [root at server22 ~]# vzctl exec 2201 cat /proc/mounts
>> /dev/ploop27939p1 / ext4
>> rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
>> proc /proc proc rw,relatime 0 0
>> sysfs /sys sysfs rw,relatime 0 0
>> none /dev tmpfs rw,relatime,mode=755 0 0
>> none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
>> none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
>>
>>  But the device is actually missing:
>>
>>  [root at server22 ~]# vzctl exec 2201 ls -l /dev/ploop27939p1
>> ls: /dev/ploop27939p1: No such file or directory
>>
>>  In fact, there doesn't seem to be ANY /dev/ploop devices in this
>> container
>>
>>  [root at server22 ~]# vzctl exec 2201 ls -l /dev/ploop*
>> ls: /dev/ploop18940: No such file or directory
>> ls: /dev/ploop18940p1: No such file or directory
>> ls: /dev/ploop26517: No such file or directory
>> ls: /dev/ploop26517p1: No such file or directory
>> ls: /dev/ploop27379: No such file or directory
>> ls: /dev/ploop27379p1: No such file or directory
>> ls: /dev/ploop27939: No such file or directory
>> ls: /dev/ploop27939p1: No such file or directory
>> ls: /dev/ploop50951: No such file or directory
>> ls: /dev/ploop50951p1: No such file or directory
>> ls: /dev/ploop52860: No such file or directory
>> ls: /dev/ploop52860p1: No such file or directory
>> ls: /dev/ploop58415: No such file or directory
>> ls: /dev/ploop58415p1: No such file or directory
>>
>>  Why does it shows devices when there are none present?   Obviously
>> something is messed up, how can we fix this?
>>
>>
>>
>>
>>  _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>    Rene C. <openvz at dokbua.com>
>>  Tuesday, January 20, 2015 12:04 PM
>>
>> No takers?
>>
>>
>>
>>  _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>    Rene C. <openvz at dokbua.com>
>>  Tuesday, January 13, 2015 12:00 PM
>>   Hm, well I removed the scripts, now I get the error:
>>
>>  repquota: Can't stat() mounted device /dev/ploop50951p1: No such file
>> or directory
>>
>>  I don't know if this is related at all, it kinda started after a recent
>> update to the latest kernel 2.6.32-042stab102.9
>>
>>  Now if I go into any container on this hardware node, the /dev/ploopXXX
>> devices listed in /proc/mount doesn't exist.
>>
>>  For example:
>>
>>  root at vps2202 [~]# cat /proc/mounts
>> /dev/ploop50951p1 / ext4
>> rw,relatime,barrier=1,stripe=256,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
>> 0 0
>> /dev/simfs /backup simfs rw,relatime 0 0
>> proc /proc proc rw,relatime 0 0
>> none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
>> sysfs /sys sysfs rw,relatime 0 0
>> none /dev tmpfs rw,relatime,size=7992992k,nr_inodes=1998248 0 0
>> none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
>> root at vps2202 [~]# ll /dev/ploop50951p1
>> /bin/ls: /dev/ploop50951p1: No such file or directory
>>
>>  There are quite a few /dev/ploop* devices under /dev, but not the one
>> linked in /proc/mounts.
>>
>> This goes for all containers on this hardware node.  Other nodes not yet
>> upgraded to the latest kernel do not have this problem.
>>
>> Any ideas?
>>
>>
>>
>>
>>
>>  _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>    Kir Kolyshkin <kir at openvz.org>
>>  Friday, December 26, 2014 6:31 PM
>>
>>
>>
>> No, the script (and its appropriate symlinks) is (re)created on every
>> start (actually mount)
>> of a simfs-based container. It is a conversion process that should get
>> rid of it, unfortunately
>> vzctl doesn't do it currently, so has to be done manually. Feel free to
>> file a bug for vzctl.
>>
>> Kir.
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>    Scott Dowdle <dowdle at montanalinux.org>
>>  Friday, December 26, 2014 12:46 PM
>>   Greetings,
>>
>> ----- Original Message -----
>>
>> What I understood Kir to say was that the script was created as part of
>> the conversion process and should have been automatically removed (like it
>> was automaically created) after the conversion was complete. Why it wasn't
>> removed I don't know... but you can back up the file somewhere else... and
>> remove it... and if you have problems... you could copy it back. I don't
>> think any of that would be necessary but who knows.
>>
>> TYL,
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20150121/eb8fb9d5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 14b0d476be48d1b7_compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/users/attachments/20150121/eb8fb9d5/attachment-0001.jpg>

More information about the Users mailing list