Re: [p4] Disk space consumed from an aborted submit - how to clean up?

Posted on behalf of forum user 'Matt Janulewicz'.

If everything is under a truly new directory and not branched, in other words,
all revision #1, all adds, all the abandoned stuff should be physically under
the same directory on the server as the depot path you created, relative to the
server's P4ROOT.

Binary files that have completely arrived at the server will have a filename
format of 1.(change_number), with possibly a .gz extension, inside a directory
named after the file with a ',d' at the end. So they should be pretty
easy to pick out. I believe files in transit will have a .tmp extension.

Automating this kind of thing kinda creeps me out so I do it manually. My advice
would be to find the files you think are extraneous and rename them, or rename
the parent directory, then do a 'p4 verify -q' of the entire server,
every depot, every file. Once you're convinced that the rename/moved server
local files are unneeded you can delete them.

-------

Sort of off topic but tangentially related, if you're type-a about this kind
of think like I am ... We are in a commit->edge environment and have various
warm standby replicas scattered about. We tend to swap new hardware into one or
another role a couple times a year. When I'm building a new replica I
sometimes populate the whole thing by doing a 'p4 verify -qt' to
explicitly transfer all the files there from the upstream source. I wouldn't
recommend rolling a new server just for the purpose of removing 30 GB of data,
but it's another approach for rolling a 'clean' server if you have
an environment with a lot of extra servers lying around.

One last thing worth noting is that 'p4 fstat -Oc' will give you
information about the server local file that relates to the revision. You'll
want to look at the lbrFile and lbrRev, which combined can give you an idea of
where the actual archive for that revision lives. You'll also have to look
at the LbrType and lbrIsLazy to distinguish it from a binary ,d/*.gz archive or
an old-school RCS ,v archive, but with a little schmoozing you could run a giant
'p4 fstat -Oc' and come up with an explicit list of archive files you
would expect to see on the server.



--
Please click here to see the post in its original format:
  http://forums.perforce.com/index.php?/topic/5706-disk-space-consumed-from-an-aborted-submit-how-to-clean-up
_______________________________________________
perforce-user mailing list  -  [email protected]
http://maillist.perforce.com/mailman/listinfo/perforce-user