ALICE native xrootd - Revision history

Diarra: /* Migration with preserving absolute file names */

2016-01-22T17:25:59Z

Migration with preserving absolute file names

← Version précédente		Version du 19:25, 22 janvier 2016
Ligne 175:		Ligne 175:
	# Ensure all the partitions are mounted in read-only before running this script:		# Ensure all the partitions are mounted in read-only before running this script:
	# service xrdservices stop		# service xrdservices stop
	# for i in $(seq 1 8); do mount -o remount /grid/xrddata$i; done		# for i in $(seq 1 8); do mount -o remount,ro /grid/xrddata$i; done
	# service xrdservices start		# service xrdservices start
	#		#

Diarra: /* The lost namespace is a subdirectory of a xrootd data partition */

2015-12-11T19:08:45Z

The lost namespace is a subdirectory of a xrootd data partition

← Version précédente		Version du 21:08, 11 décembre 2015
Ligne 564:		Ligne 564:
	1) service xrootdservices stop		1) service xrootdservices stop

	2) Create the directory to restore the namespace. For example repair/recreate the namespace partition and mount it. Update ~~if necessary~~ the xrootd config file.		2) Create the directory to restore the namespace. For example repair/recreate the namespace partition and mount it. Update the xrootd config file if necessary.

	3) Populate the namespace for files still existing :		3) Populate the namespace for files still existing :

Diarra: /* The lost namespace is in a separate disk partition */

2015-12-11T18:59:31Z

The lost namespace is in a separate disk partition

← Version précédente		Version du 20:59, 11 décembre 2015
Ligne 536:		Ligne 536:
	1) service xrootdservices stop		1) service xrootdservices stop

	2) Create a place to restore the namespace. For example repair/recreate the namespace partition and mount it. Update ~~if necessary~~ the xrootd config file.		2) Create a place to restore the namespace. For example repair/recreate the namespace partition and mount it. Update the xrootd config file if necessary.

	3) Populate the namespace:		3) Populate the namespace:

Diarra: /* The lost namespace is in a separate disk partition */

2015-12-11T17:25:07Z

The lost namespace is in a separate disk partition

← Version précédente		Version du 19:25, 11 décembre 2015
Ligne 536:		Ligne 536:
	1) service xrootdservices stop		1) service xrootdservices stop

	2) Create a place to restore the namespace ~~and update if necessary the xrootd config file~~. For example repair/recreate the namespace partition and mount it.		2) Create a place to restore the namespace. For example repair/recreate the namespace partition and mount it. Update if necessary the xrootd config file.

	3) Populate the namespace:		3) Populate the namespace:

Diarra: /* The lost namespace is a subdirectory of a xrootd data partition */

2015-12-11T17:24:21Z

The lost namespace is a subdirectory of a xrootd data partition

← Version précédente		Version du 19:24, 11 décembre 2015
Ligne 564:		Ligne 564:
	1) service xrootdservices stop		1) service xrootdservices stop

	2) Create the directory to restore the namespace. For example repair/recreate the namespace partition and mount it.		2) Create the directory to restore the namespace. For example repair/recreate the namespace partition and mount it. Update if necessary the xrootd config file.

	3) Populate the namespace for files still existing :		3) Populate the namespace for files still existing :

Diarra: /* The lost namespace is in a separate disk partition */

2015-12-11T17:23:03Z

The lost namespace is in a separate disk partition

← Version précédente		Version du 19:23, 11 décembre 2015
Ligne 536:		Ligne 536:
	1) service xrootdservices stop		1) service xrootdservices stop

	2) Create a place to restore the namespace. For example repair/recreate the namespace partition and mount it.		2) Create a place to restore the namespace and update if necessary the xrootd config file. For example repair/recreate the namespace partition and mount it.

	3) Populate the namespace:		3) Populate the namespace:

Diarra: /* Why Monalisa continue to monitor decomissionned xrootd servers ? */

2015-12-01T09:11:05Z

Why Monalisa continue to monitor decomissionned xrootd servers ?

← Version précédente		Version du 11:11, 1 décembre 2015
Ligne 605:		Ligne 605:
	Monalisa will continue to monitor a decommissioned xrootd server and reports errors. It will eventually give up trying to write to servers that are no longer active. Unless the record is manually removed, it has no idea if you decommissioned the server, it has hanged, powered down or has any connectivity issues but if the server doesn't report any monitoring data for one month it probably means it is a feature.		Monalisa will continue to monitor a decommissioned xrootd server and reports errors. It will eventually give up trying to write to servers that are no longer active. Unless the record is manually removed, it has no idea if you decommissioned the server, it has hanged, powered down or has any connectivity issues but if the server doesn't report any monitoring data for one month it probably means it is a feature.

	To remove the decommissioned server from the monitoring, ALICE intervention is required.		To remove the decommissioned server from the monitoring, ALICE intervention is required or just wait for one month.

	The status of all the xrootd servers for a SE (ex: ALICE::GRIF_IPNO::SE) can be visible at:		The status of all the xrootd servers for a SE (ex: ALICE::GRIF_IPNO::SE) can be visible at:
	http://alimonitor.cern.ch/stats?page=xrootdse/table&cluster=ALICE::GRIF_IPNO::SE		http://alimonitor.cern.ch/stats?page=xrootdse/table&cluster=ALICE::GRIF_IPNO::SE

Diarra: /* Should I set a xrootd server in read-only mode when decomissioning ? */

2015-11-23T10:27:26Z

Should I set a xrootd server in read-only mode when decomissioning ?

← Version précédente		Version du 12:27, 23 novembre 2015
Ligne 587:		Ligne 587:
	== Should I set a xrootd server in read-only mode when decomissioning ?==		== Should I set a xrootd server in read-only mode when decomissioning ?==

	You could first stop the xrootd service, remount ro and start it again. Any transfers in progress will fail but this is not a problem, there are fallbacks for both writing and reading. While doing this you can also add		Yes.

			You could first stop the xrootd service, remount xrootd partitions in read-only mode and start xroot service again. Any transfers in progress will fail but this is not a problem, there are fallbacks for both writing and reading. While doing this you can also add
	oss.readonly		oss.readonly
	to xrootd's configuration to make it aware of the situation.		to xrootd's configuration to make it aware of the situation.

Diarra: /* FAQ */

2015-11-23T10:20:04Z

FAQ

← Version précédente		Version du 12:20, 23 novembre 2015
Ligne 585:		Ligne 585:
	This FAQ is a collection of Questions/Answers exchanged on the alice-lcg-task-force@cern.ch .		This FAQ is a collection of Questions/Answers exchanged on the alice-lcg-task-force@cern.ch .

	== ~~Setting~~ a xrootd server in read-only mode when decomissioning ==		== Should I set a xrootd server in read-only mode when decomissioning ?==

	You could first stop the xrootd service, remount ro and start it again. Any transfers in progress will fail but this is not a problem, there are fallbacks for both writing and reading. While doing this you can also add		You could first stop the xrootd service, remount ro and start it again. Any transfers in progress will fail but this is not a problem, there are fallbacks for both writing and reading. While doing this you can also add
Ligne 593:		Ligne 593:
	While migrating the data to server B it would be best if A would still be active to serve the existing files, even if this makes the data migration longer. It will be mitigated by the [[#File_duplications_during_migration_from_server_A_to_B:_not_harmful\|following point]] .		While migrating the data to server B it would be best if A would still be active to serve the existing files, even if this makes the data migration longer. It will be mitigated by the [[#File_duplications_during_migration_from_server_A_to_B:_not_harmful\|following point]] .

	== ~~File duplications~~ during migration from server A to B~~: not~~ harmful ==		== Is files duplication during migration from server A to B harmful ? ==

			No, it not harmful.

	The redirector broadcasts the request to the cluster, if both A and B reply they have a file the first one to answer will get the connection. There is no problem to have the same file on several disk servers, in fact you can do this to improve the performance of reading "hot files". As such A should get less requests as B has more of its files.		The redirector broadcasts the request to the cluster, if both A and B reply they have a file the first one to answer will get the connection. There is no problem to have the same file on several disk servers, in fact you can do this to improve the performance of reading "hot files". As such A should get less requests as B has more of its files.

	== Monalisa ~~monitoring of~~ decomissionned xrootd servers ==		== Why Monalisa continue to monitor decomissionned xrootd servers ? ==

	Monalisa will continue to monitor a decommissioned xrootd server and reports errors. It will eventually give up trying to write to servers that are no longer active. Unless the record is manually removed, it has no idea if you decommissioned the server, it has hanged, powered down or has any connectivity issues but if the server doesn't report any monitoring data for one month it probably means it is a feature.		Monalisa will continue to monitor a decommissioned xrootd server and reports errors. It will eventually give up trying to write to servers that are no longer active. Unless the record is manually removed, it has no idea if you decommissioned the server, it has hanged, powered down or has any connectivity issues but if the server doesn't report any monitoring data for one month it probably means it is a feature.

Diarra: /* Less easy merge */

2015-11-21T20:07:51Z

Less easy merge

← Version précédente		Version du 22:07, 21 novembre 2015
Ligne 146:		Ligne 146:

	You will need this list to update the namespace on serrver B.		You will need this list to update the namespace on serrver B.
	See [[#~~Copy_when_absolute_file_names_can~~.27t_be_preserved]] for the copy and merging procedure and for the script to create the files list.		See [[#Migration_when_absolute_file_names_can.27t_be_preserved]] for the copy and merging procedure and for the script to create the files list.

	=== Migration with preserving absolute file names ===		=== Migration with preserving absolute file names ===