BeeGFS v7.4.3 Upgrade Guide

Please read and understand the information below completely before attempting the upgrade.

Possible upgrade paths

The following upgrade paths from older versions are supported:

• v2014.01 ⟶ v6.19 ⟶ v7.4.3

• v2015.03 ⟶ v6.19 ⟶ v7.4.3

• v6.x ⟶ v7.4.3

• v7.x ⟶ v7.4.3

When upgrading from v2014.01 or v2015.03, an intermediate step is required. Upgrade to v6.19 by following the upgrade instructions in the Wiki under https://www.beegfs.io/wiki and/or the respective upgrade notes under https://www.beegfs.io/release. After that, start the management daemon at least once. You can then proceed with procedure below.

Upgrade to v7.4.3

Note

A backup of the system after stopping all services and before upgrading packages from versions older than 7.4.3 is recommended.

Warning

All buddies have to be in the GOOD state before upgrading to this release.

1. If you use buddy mirroring, make sure that all buddies are in GOOD state.

2. Stop the BeeGFS system:

   • stop/unmount all clients

   • stop all storage daemons

   • stop all meta daemons

   • stop the management daemon

3. Create a full BeeGFS backup if possible, backup the configuration files of all servers (see Backup).

4. Upgrade all BeeGFS packages.

5. Check the configuration files. Some configuration options are no longer valid and have to be removed (see Release Notes v7.4.3).

6. Start all daemons and clients and verify that the system works as expected.

Upgrade from 7.4.x

Warning

Necessary changes to a message used in metadata hard link creation cause an incompatibility between 7.4.3 metadata services and metadata services running other 7.4.x versions. It is therefore necessary to upgrade all metadata nodes in a BeeGFS system to 7.4.3 at once. Rolling upgrades of metadata services from older versions are not supported. All services other than metadata are not affected by this and can be upgraded in a rolling fashion or used together with other 7.4.x versions.

Hard links migration

Note

Before cross-directory hard links were supported, the client sysCreateHardlinksAsSymlinks option could be used as a workaround to create a symlink when an application tried to create a hard link. Ensure to this is set to false on all clients that should be able to create true cross-directory hard links.

The following BeeGFS components have been changed to add support for cross-directory hard links:

• beegfs-client

• beegfs-meta

• beegfs-fsck

• beegfs-ctl

If there are hard links (same directory) present in you BeeGFS file system, they should be migrated to the new de-inlined format. If not migrated, old-style hard links will continue to work, but they can’t be moved because their on-disk formats are still use inlined inodes. Hard links created in version 7.4.3 will always use the new format.

To facilitate migration, we have introduced a new beegfs-fsck --checkfs mode called checkAndUpdateOldStyledHardlinks that can be used to detect and migrate old-style hard links to the new format. We recommend the following procedure:

1. Upgrade system to version 7.4.3 and start all BeeGFS server services.

2. Ideally, leave clients offline until the migration is finished. This is not strictly necessary, but we recommend against running beegfs-fsck repair operations other than migrating the hard link format while the file system is online.

3. Run beegfs-fsck --checkfs --checkOldStyledHardlinks --readonly to check if a migration is necessary. If no old-style hard links are found, the file system is ready to go.

4. If old-style hardlinks are detected, you have two options:

   • Either rerun beegfs-fsck --checkfs --checkOldStyledHardlinks without the --readonly flag and choose “Update metadata…” for all files.

   • Or remove all but one of the links for each file that is found and recreate hard links using ln. They will automatically be created in the new format.

5. After beegfs-fsck finishes without errors, the file system can be opened up to clients again. All hard links will now use the new format.