Translations:Known issues/4/en: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(Importing a new version from external source)
(Importing a new version from external source)
Line 5: Line 5:
** We are restoring files to a separate location, then moving the broken file elsewhere, and moving the restored file into place.  This is happening incrementally, and every restored file is noted in another per-project list (.files_restored).
** We are restoring files to a separate location, then moving the broken file elsewhere, and moving the restored file into place.  This is happening incrementally, and every restored file is noted in another per-project list (.files_restored).
** Based on the overall number of files affected, we expect the entire process to take 8-10 days.  The particular order of files restored depends on tape scheduling, so is difficult to predict.
** Based on the overall number of files affected, we expect the entire process to take 8-10 days.  The particular order of files restored depends on tape scheduling, so is difficult to predict.
* Compute nodes cannot access Internet
** Solution: Contact [[Technical Support|technical support]] to request exceptions to be made; describe what you need to access and why.

Revision as of 19:48, 15 January 2019

Information about message (contribute)
This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.
Message definition (Known issues)
===Graham===
Graham's /scratch is often slow; it will be replaced soon.

Graham only

  • A component of the /project filesystem malfunctioned while returning to service as described here. Some details of the restoration process:
    • A list of affected files (.files_being_restored) is in the base directory of each project. For privacy reasons, this list is only readable by the project owner (sponsor or PI).
    • Affected files behave oddly: they cannot be removed (because they make reference to an offline storage component, so a failure is returned when trying to deallocate). They can be moved, though (the "mv" command doesn't work though.) Affected files will show up in directory listings with "?" in some fields.
    • We are restoring files to a separate location, then moving the broken file elsewhere, and moving the restored file into place. This is happening incrementally, and every restored file is noted in another per-project list (.files_restored).
    • Based on the overall number of files affected, we expect the entire process to take 8-10 days. The particular order of files restored depends on tape scheduling, so is difficult to predict.