Jump to content


Perforce Sever (Linux) Disk Space Issue

space disk perforce p4v p4

  • Please log in to reply
4 replies to this topic

#1 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 08 March 2020 - 04:20 PM

Hey,

Recently started using perforce. I followed some online guides to get perforce installed on a linux server running on a Microsoft Azure VM. Everything seems to work ok and I think I got it set up ok.

I did a push of small files and they worked to the depot! So last night and all of today I did a big push of all the files (40GB) in my project and it took 18 hours to get this message:

Posted Image

Looks to me like the server ran out of space. Doesn't even look like it saved any of my upload... Thanks perforce.

I checked on my VM and I have a 256GB HDD space, but there's also this 30GB OS HDD. I'm worried it might be using that for some reason

Posted Image

Can someone please help with what to do? I can SSH using PuTTY into the Linux server, but I'm new to this and really need some guidance. I followed various online guides to get me this far but can't find anything on trying to resolve this.

Thanks,

#2 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 204 posts
  • LocationAustin. Texas. Y'all.

Posted 17 March 2020 - 08:12 PM

Where does "p4 configure show | grep /" say things are stored?

#3 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 224 posts
  • LocationSan Diego, CA

Posted 17 March 2020 - 10:33 PM

I think 'p4 info' might also show server root ...? Is it set to /tmp? Hopefully not.

In any case, it's trying to write temp files to /tmp, which is typically very small. It uses the system's 'TMP' or 'TEMP' environment variables. You'll likely want to change that to a directory on your bigger disk.

I don't have access to a server right now, but I know during transfer between replicas the temp files are written to the same directories they will ultimately end up in, the they're renamed in place when the transfer is done. I wasn't aware that it uses /tmp during submits, probably because the SDP (look into that, it's insanely useful) puts the temp directory in your man library storage volume (or is it logs? I forget.)

From a philosophical/performance standpoint, this seems to insinuate that transfers go to /tmp then are moved to a different volume during a submit. Perforce might consider changing this to work the way replication works so there's not an extra volume to volume transfer there (unless I'm wrong about what it's doing.)
-Matt Janulewicz
Currently unemployed, looking for work in Boise, ID!

#4 subressor

subressor

    Member

  • Members
  • PipPip
  • 11 posts

Posted 01 April 2020 - 10:37 AM

Hey guys, thanks for the responses.

I did some investigation from @Miles O'Neal "p4 configure show | grep /" and Azure system view and it looks like it installed itself onto the main drive and tried to store everything there, which filled up.

Azure, unlike AWS, doesn't expand your main drive, it just attaches another drive you provision. I didn't mount the disk or do any linux config.

It looks like Perforce just tried to make the depot on the main OS disk (maybe under its install root) and filled that up. I have tried fiddling with this on a windows system and you can 'Map' the depot files to another disk which seems to work. But I feel that makes everything messy.

I moved over to AWS, which by default expands your main OS disk to the size you want and installed/uploaded fine without any issues :-)

I now have another issue (lost my depot!), but have made a separate thread :-)

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1148 posts

Posted 01 April 2020 - 01:58 PM

View Postsubressor, on 01 April 2020 - 10:37 AM, said:

It looks like Perforce just tried to make the depot on the main OS disk (maybe under its install root) and filled that up. I have tried fiddling with this on a windows system and you can 'Map' the depot files to another disk which seems to work. But I feel that makes everything messy.

The easy fix would be to just move your entire P4ROOT directory to the larger disk, keeping the depots in their relative paths under P4ROOT.





Also tagged with one or more of these keywords: space, disk, perforce, p4v, p4

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users