Skip to content

Conversation

@nreich
Copy link

@nreich nreich commented Oct 20, 2017

  • Oplog files that are backed up are read-only. For this reason,
    they can be transfered to the backup location through hard links,
    instead of copying the file. This change improves speed of backups.
    If the creation of a hard link fails, we revert to the existing copy
    behavior.
  • During backups, the copying of the oplog's krf file was being done while
    that file could still be in the process of writing. This change ensures
    that if a krf is to be written, that it is finished and included in the
    backup
  • cleanup existing oplog tests

  * Oplog files that are backed up are read-only. For this reason,
    they can be transfered to the backup location through hard links,
    instead of copying the file. This change improves speed of backups.
    If the creation of a hard link fails, we revert to the existing copy
    behavior.
  * During backups, the copying of the oplog's krf file was being done while
    that file could still be in the process of writing. This change ensures
    that if a krf is to be written, that it is finished and included in the
    backup
  * cleanup existing oplog tests
Copy link
Contributor

@kirklund kirklund left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks good to me except the one log statement I commented on.

try {
Files.createLink(targetDir.toPath().resolve(file.getName()), file.toPath());
} catch (IOException | UnsupportedOperationException e) {
logger.warn("Unable to create hard link for + " + targetDir + ". Reverting to file copy");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have an extra + after inside the log statement quotes.

The Log4J2 way is to use their parameters:

logger.warn("Unable to create hard link for {}. Reverting to file copy", targetDir);

Copy link
Contributor

@kirklund kirklund left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link

@pivotal-eshu pivotal-eshu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

private void backupFile(File targetDir, File file) throws IOException {
if (file != null && file.exists())
try {
Files.createLink(targetDir.toPath().resolve(file.getName()), file.toPath());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason you cannot use a symbolic link here? That way it would allow the link to span filesystems too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of a hard link here is to replace the existing logic of making a copy of the original file for the backup. Deletion of the original file cannot be allowed to result in loss of that file in the backup location and thus a symbolic link cannot be used in this case. Hard links can be used here in place of copying the file only because the Oplog files being copied are guaranteed to be read-only.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - that makes sense. Thanks for the explanation.

@nreich nreich merged commit 6a4e50e into apache:develop Oct 24, 2017
@nreich nreich deleted the feature/GEODE-3801 branch October 24, 2017 15:24
kirklund added a commit to kirklund/geode that referenced this pull request Nov 2, 2017
…pache#963)"

This reverts commit 6a4e50e.

The revision is causing a hang in Backup which is filed as
GEODE-3940.
kirklund added a commit to kirklund/geode that referenced this pull request Nov 3, 2017
…pache#963)"

This reverts commit 6a4e50e.

The revision is causing a hang in Backup which is filed as
GEODE-3940.
lgallinat pushed a commit that referenced this pull request Nov 3, 2017
…963)"

This reverts commit 6a4e50e.

The revision is causing a hang in Backup which is filed as
GEODE-3940.
kirklund pushed a commit that referenced this pull request Nov 6, 2017
* Oplog files that are backed up are read-only. For this reason,
  they can be transfered to the backup location through hard links,
  instead of copying the file. This change improves speed of backups.
  If the creation of a hard link fails, we revert to the existing copy
  behavior.
* During backups, the copying of the oplog's krf file was being done while
  that file could still be in the process of writing. This change ensures
  that if a krf is to be written, that it is finished and included in the
  backup
* cleanup existing oplog tests
kirklund pushed a commit that referenced this pull request Nov 7, 2017
* Oplog files that are backed up are read-only. For this reason,
  they can be transfered to the backup location through hard links,
  instead of copying the file. This change improves speed of backups.
  If the creation of a hard link fails, we revert to the existing copy
  behavior.
* During backups, the copying of the oplog's krf file was being done while
  that file could still be in the process of writing. This change ensures
  that if a krf is to be written, that it is finished and included in the
  backup
* cleanup existing oplog tests
smgoller pushed a commit to smgoller/geode that referenced this pull request Nov 13, 2017
…pache#963)"

This reverts commit 6a4e50e.

The revision is causing a hang in Backup which is filed as
GEODE-3940.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants