Jump to content


Conflicting docs: obliterate vs terminate

documentation obliterate terminate monitor

  • Please log in to reply
6 replies to this topic

#1 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 128 posts

Posted 07 May 2019 - 10:13 PM

Per https://community.pe.../s/article/3785 (Fixing a Hung helix Server):

"In any case, you may want to use "p4 monitor terminate <pid>" to remove a process or thread as mentioned above.  If CPU and memory is at 100%, run "p4 monitor terminate <pid>" to kill the high resource command, then re-run the command with less files (such as running "p4 obliterate", "p4 integrate" or "p4 revert" on a smaller directory at a time)."

And yet https://www.perforce...p4_monitor.html (p4 monitor) states:

"Some commands, such as p4 obliterate, cannot be terminated."

Is the latter a new thing in 2019.1 ? Or is one of these in error?

NOTE: Emphasis mine.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 894 posts

Posted 07 May 2019 - 11:02 PM

IIRC (and I might well be out of date), they're both in error.  There's a certain window during which an obliterate can be terminated and a window during which it can't, so it's incorrect to state unequivocally that it either can or can't be terminated.

#3 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 128 posts

Posted 07 May 2019 - 11:17 PM

Schrodinger's obliterate!
I don't suppose there's any easy way to tell which window one is in.
Side note: obliterating a spec client with hundreds of thousands of versions (automaton gone berserk) without using a client for the obliterate is taking hours on a test box. Hopefully the next test (with "-h" makes it manageable, but I suspect it's still untenable for production.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 894 posts

Posted 07 May 2019 - 11:27 PM

View PostMiles O, on 07 May 2019 - 11:17 PM, said:

I don't suppose there's any easy way to tell which window one is in.

The easiest way is to run "p4 monitor terminate" on it.  If it terminates right away, it's in the window where terminate works.  If it keeps running, it's not.

When I used to do a lot of test/obliterate/retest cycles with lots of small files on a test server, "obliterate -ahy" was firmly ingrained in my muscle memory as the "standard" version of the command because those "-ah" flags make obliterate work *much* faster.  I always thought "-h" should have been the default behavior, because it lets "p4 sync" clean up the workspace rather than leaving orphaned files everywhere.  The "-a" is a little sketchier since it can lead to orphaned archive files that use up disk space, but if your automation-gone-berserk was branching files rather than adding new ones, or if the files it was adding were small enough as to be negligible, it's a pretty huge performance win.

#5 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 128 posts

Posted 08 May 2019 - 12:12 AM

Yeah. I had definitely meant to use the -h on this one, as we blocked this client from the spec depot, so there should never be a db.have entry. That's why I want to restore the data again and rerun it with -h.

Which is how this post started. I typed "p4 obliterate -y foo", and as soon as I hit it, I went, "Oh, carp!" and hit CTL-C. But the band plays on in the background. I guess I oculd terminate it and see what happens but I also realized I needed to know in general. Without -h, the log entries for the 750k+ versions are just crawling by.

#6 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 128 posts

Posted 08 May 2019 - 12:24 AM

Welp, it appears it was interruptible two+ hours in, with no ill effects, and early versions obliterated. Rerunning with -h seems a bit faster but still slow. Same with a client. Ugly mess.
At least my question is answered. Thanks!

#7 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 176 posts
  • LocationSan Francisco, CA

Posted 08 May 2019 - 07:38 AM

My typical obliterate routine:

0. Try to find a way out of it.
1. Run 'p4 fstat -Oc -Of -F lbrIsLazy=0' on the path so I have a record of what the archive files should be (lbrFile.)
2. p4 obliterate -ah followed by p4 obliterate -ayh.
3. Remove archive files gleaned from fstat.

Notes:

1. We (more or less) have no RCS files so we have little risk of accidentally deleting a ,v file that has remaining revisions in it.
2. Our backup servers take snapshots every day so we have ready access to anything that was accidentally deleted.
3. We seem to swap various servers around twice a year or so, so sometimes I'll not worry about it and build out the next new server in a pedantic way (p4 verify -qt) so the cruft will be skipped.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com





Also tagged with one or more of these keywords: documentation, obliterate, terminate, monitor

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users