# Huge allocation overwritten by storagenode **URL:** \ **Category:** troubleshooting\ **Created:** [July 9, 2024, 12:06am UTC](https://forum.storj.io/t/huge-allocation-overwritten-by-storagenode/27010 "2024-07-09T00:06:47Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\ **Post date:** [July 9, 2024, 12:06am UTC](https://forum.storj.io/t/huge-allocation-overwritten-by-storagenode/27010/1 "2024-07-09T00:06:47Z")
If you allocate more space than the drive’s capacity, the storagenode will overwrite the value with the real capacity of the drive and display it on the dashboard. So, if you see a discrepancy between dashboard and OS, about occupied space (like in the recent trash problems, when the database isn’t updated after the TTL pieces are deleted), the recomended workaround is to allocate more space than drive’s capacity, if the drive is only used for storagenode, to still get ingress. It seems that the software ignores the value if it’s bigger than the actual capacity of the drive, so the workaround dosen’t work. I see this in ver 105, on Ubuntu Server/Docker. I have 2 drives of 22TB used only for storj. As I expirienced the usage discrepancy, I set 40TB allocated space for each, to continuu geting ingress, because I had enough free space, wrongly reported as occupied. But the dashboard shows 21.9TB allocated space. ---
**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\ **Post date:** [July 9, 2024, 12:44am UTC](https://forum.storj.io/t/huge-allocation-overwritten-by-storagenode/27010/2 "2024-07-09T00:44:59Z")
In your example did the OS also show the extra fake capacity (40TB)… or only the real 22TB? I can’t remember if you’re one of the people experimenting with ZFS: but it lets you make ‘sparse volumes’ where the reported size is larger than the real size. (So you could make 22TB of real space report as 40TB of space at the OS level… then as you actually start to fill you can add more real space later so you never _really_ run out) ---
**Author:** ![jammerdan](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jammerdan/32/1121_2.png) [@jammerdan](https://forum.storj.io/u/jammerdan)\ **Post date:** [July 9, 2024, 1:05am UTC](https://forum.storj.io/t/huge-allocation-overwritten-by-storagenode/27010/3 "2024-07-09T01:05:57Z")
Has been mentioned already here: > [@Overriding available space?](https://forum.storj.io/t/overriding-available-space/26621): > > I had to disable the filewalker on this node as it would not finish. Now of course the used space is not correct and I cannot let it correct it. The node believes it is full, however according to df there it 1.4 TB free. It does not accept any more uploads. But I cannot raise the available space due to this change I guess: as it is already at max space. So no matter what I enter in the docker run command, it remains at the max disk size. So what can I do, is there a way to override this? It seems there was a fix that now prevents the override that would help to bandaid the problems that come from the usage discrepancies. ---
**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\ **Post date:** [July 9, 2024, 4:26am UTC](https://forum.storj.io/t/huge-allocation-overwritten-by-storagenode/27010/4 "2024-07-09T04:26:16Z")
So this is the wanted behavior, introduced in 1.98 version. I don’t know why they did this, but should be reverted back. I use ext4, and the drive has 22TB. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [July 9, 2024, 7:12am UTC](https://forum.storj.io/t/huge-allocation-overwritten-by-storagenode/27010/5 "2024-07-09T07:12:39Z")
Node always select the minimum of the “allocated” and “used + free (in the allocation)” and “used + free (on the disk)”. Of course the “used” value is taken from the databases… However, it’s calculated only on restart as far as I know.