In my company we're using a perforce and last time we started to receive "The filesystem 'P4LOG' has only XXX free, but the server configuration requires at least YYY available". What does it means. I tried to google and all I found is that this is env variable - Name and path of the file to which Perforce errors are written. We asked our administrator to fix the problem and he increased min file size, that removes an error for some time but later it appears again. Why this warning appears? How to prevent it?
Your administrator can either set up Perforce's specific log rotation tool, or use the standard Linux logrotate tool. This is essential if you don't want to keep running out of disk space on the Perforce server.
As the p4 logrotate docs mention, p4 logrotate happens automatically on a checkpointing or journaling event. You should have checkpointing and journaling set up so that you don't run the risk of losing your entire depot if the p4 server has a problem.
Your administrator needs to let up log rotation. Log rotation will compress recent logs and remove old ones.
Related
I'm working with the unreal engine so when Epic does an update to the engine, there can be a need to update 100k files or more. The perforce server sits in an AWS instance.
The normal way to manage unreal engine updates, even recommended by perforce, is to write over the local files and use 'reconcile' to find the changes.
The reconcile on my laptop which was cutting edge maybe 3 years ago takes 12 hours and then fails silently.
If I manage to make the proper changelist, by adding things little by little, and I hit submit, it takes 12 hours and fails silently.
Doing a submit in p4v will "jam" perforce (the process will stall indefinitely and when killed no other perforce command will complete, even trivial ones). The only way to get perforce commands working again is to reboot the client computer.
When using the command line interface, commands like reconcile or submit have no useful output as to what is going on and return error messages such as:
Some file(s) could not be transferred from client.
Submit aborted -- fix problems then use 'p4 submit -c 1996'
Anything I can do to speed these things up or figure out what is perforce choking on?
To debug the failing submit, repeat it from the command line. The command line client will show you output for each file in the changelist, along with an error message for any where the transfer failed:
C:\Perforce\test\submit>p4 submit -d "Test submit"
Submitting change 312.
Locking 2 files ...
add //stream/main/submit/bar#1
add //stream/main/submit/foo#1
open for read: c:\Perforce\test\submit\foo: The system cannot find the file specified.
Submit aborted -- fix problems then use 'p4 submit -c 312'.
Some file(s) could not be transferred from client.
In the above example, note that the system error message (The system cannot find the file specified.) is printed on the line immediately before Perforce's Submit aborted error. P4V will sometimes obscure this error by displaying it in a different place from the top-level error message, or not displaying it at all, but from the CLI you should always be able to find it by scrolling up in the terminal.
If the server is "jammed" when trying to open or submit 100k files, it suggests that it's under-resourced; Perforce installations scale to millions of files easily, but the hardware needs to be available to support that. Memory is the most typical bottleneck so the first thing I'd check/adjust would be the memory allocation for your AWS instance.
for a project I usually create several workspaces on the same host to work on different aspect of the project. However I've find that the workspaces that I stop using for more than a couple weeks disappears(I don't interact with it through command line or GUI). and I'd get a 'clientroot missing' error. The workspace folder is still on my local drive. Is there a limit to how many workspace one can create on 1 host/how long a workspace can stay inactive before being deleted? Is there a way for me to get it back somehow?
Thanks!
This isn't normal behavior for Perforce and my guess is that your admin is running some sort of home-made cleanup script, which is probably unnecessary or at the very least overzealous (unless you're using the free version and limited on how many workspaces you can create, in which case I'd suggest changing your workflow to not burn so much of a limited resource).
If that is the case, you'll need to talk to your admin about exactly what the rules are and whether the workspaces are being archived in any way before they're purged.
I have an issue related to how to incremental backup MySQL workbench.
Can anyone tell me the script to backup this?
I want to back up all day and keep incremental with difference file.
Can anyone give me the sample script about that?
Thank,
Veasna.
The binary log (mysql-bin.log) is essentially an incremental back-up. It allows you to revert back to a previously stable database state.
see http://dev.mysql.com/doc/mysql-backup-excerpt/5.0/en/backup-policy.html
Making Incremental Backups by Enabling the Binary Log,
http://dev.mysql.com/doc/refman/5.6/en/backup-methods.html
May i know from where you are restarting the service, through command prompt Or from your control panel.
Share your error message here, you Will get further details if anyone knows.
I was wondering if anyone had any advice on how to do the following task in p4v (I am not too familiar with P4V commands, so apologise if this is some basic command that I am missing).
Currently I have a workspace setup and data synced to my root
e.g. C:\Data\
I access this workspace from two different windows machine. (data is on both machines at c:\Data
Now, I need to move the location of where the data is stored on ONE of the machines and not the other (Machine A : c:\Data, Machine B: D:\Data\
Is this possible to do, without having to sync all the data again from the server (there is a lot and bandwidth limitations).
My initial thoughts were to create another workspace pointing to another root, but I do not know how to get this new workspace pick up the data files at this location.
Any help would be greatly appreciated
Thanks in advance
I don't know of a way to do this through P4V, but it can be done with the command line client. Here's the procedure.
After you have moved your files on machine B, and created a new workspace (without performing an "update all"), you can pass the -k switch to the sync command to let the server know what files you have.
From the web page to which I linked:
Keep existing workspace files; update the have list without updating
the client workspace. Use p4 sync -k only when you need to update the
have list to match the actual state of the client workspace.
And the command line help has this to say:
The -k flag updates server metadata without syncing files. It is
intended to enable you to ensure that the server correctly reflects
the state of files in the workspace while avoiding a large data
transfer. Caution: an erroneous update can cause the server to
incorrectly reflect the state of the workspace.
FYI: p4 flush is an alias for p4 sync -k
You can also look at the AltRoots field in the workspace. You could have one root at c:\data and the other at d:\data. As raven mentioned since the data is living on two separate disks you'll need to make sure that the data is kept in sync on both machines, although I assume you've already figured this part out since you've been running on two machines.
Any reason you can't just have one workspace per machine?
I have a large Perforce depot and I believe my client currently has about 2GB of files that are in sync with the server, but what's the best way to verify my files are complete, in-sync, and up to date to a given change level (which is perhaps higher then a handful of files on the client currently)?
I see the p4 verify command, and it's MD5s, but these just seem to be from the server's various revisions for the file. Is there a way to compare the MD5 on the server with the MD5 of the revision required on my client?
I am basically trying to minimize bandwidth and time consumed to achieve a complete verification. I don't want to have to sync -f to a specific revision number. I'd just like a list of any files that are inconsistent with the change level I am attempting to attain. Then I can programmatically force a sync of those few files.
You want "p4 diff -se".
This should do an md5 hash of the client's file and compare it to the stored hash on the server.
Perforce is designed to work when you keep it informed about the checked out status of all your files. If you or other programmers in your team are using perforce and editing files that are not checked out then that is the real issue you should fix.
There is p4 clean -n (equivalent to p4 reconcile -w -n)
which would also get you a list of files that p4 would update. Of course you could also pass a changelist to align to.
You might want to disable checking for local files that it would delete tho!
If you don't have many incoming updates one might consider an offline local manifest file with sizes and hashes of all the files in the repository. Iterating over it and checking for existence, size and hash yielding missing or changed files.
In our company, having the p4 server on the intranet checking via local manifest it's actually not much faster than asking for p4 clean. But a little!! And it uses no bandwidth at all. Now over internet and VPN even better!!