On Thu, Nov 19, 2009 at 09:41:15AM +0100, Andre Timmermann wrote: > Hello Herbert, hello list, > Am Samstag, den 14.11.2009, 17:11 +0100 schrieb Herbert Poetzl: >> > As far, as I can see, space_total is limited to 2^32 - 1 = 4294967295 >> correct, that is not only a limitation of vdlimit, >> but also of the kernel interface (which uses uint32_t too) >>> On line 85 of >>> http://svn.linux-vserver.org/projects/util-vserver/browser/trunk/src/vdlimit.c >>> I see an "uint32_t" which seemes to be the limiting factor. >>> I can't write C so I can't fix it, but perhaps this helps ;) >> the question is, do you really need more? >> space_total and space_used is in kilobyte, so 2^10 bytes >> that makes a total max of 2^41 (there are some special values) >> or 2TB, which usually should suffice for guest limits >> present a case why you need more than that and we might >> extend the interface to cover all 2^64 accounted bytes >> (i.e. 16EB, exa bytes) > The case is very simple, we have got a vserverguest which needs more > than 2 TB diskspace ;) We are using a vserverguest in favour of a > dedicated machine to be independent from the hardware itself. so the machine holds a single guest? > The quota is a very easy way to monitor the diskspace. > I have seen, that there seemes to be an inconsitence between the > kernelinterface and vdlimit. I am able to set 4 TB quota (2^32-1): > /usr/sbin/vdlimit --xid 60144 --set space_used=2069262452 \ > --set space_total=4294967295 --set inodes_used=1185528 \ > --set inodes_total=286501273 /var/lib/vservers/vguest/ > The vdlimit shows a negative value: which is a minor bug, replacing the %d or %ld with %u or %lu in the printf should fix that (haven't looked at the code, so just a guess :) > /usr/sbin/vdlimit --xid 60144 /var/lib/vservers/vguest/ > 60144 /var/lib/vservers/vguest/ > space_used=-2045859808 > space_total=-1 > inodes_used=7230176 > inodes_total=286501273 > reserved=5 > The vguest shows the correct values: > # df -h > Filesystem Size Used Avail Use% Mounted on > /dev/hdv1 4.5T 2.1T 2.2T 50% / yep, as I said, the kernel already uses 64bit values to account for disk limits > I understand, that the kernel ist using uint32, too, but I > think this should be raised in future as diskspace is pretty > cheap and there will be other users hit by this limitation. uint32_t is only used to communicate with userspace and obviously you are the first person to actually hit that limit :) > As I am not a kernelhacker, I cant evaluate the drawbacks of > raising this value within the kernel and the vserver-tools. there are no real drawbacks in adding a 64bit interface to the disk limit accounting system (in addition to the 32bit one) but of course, it's a lot of work (mostly testing) for kernel and userspace ... > Perhaps you can give me a hint. we need to define a new syscall command capable of setting and getting the 64bit values from userspace then we need to add that interface to vdlimit so that it can actually be used, and finally all that needs testing with limits above 2/4TB, so it might become a question of disk space too :) best, Herbert > Best regards, > Andre