Network failure for a node and new ID

[Francesco Zanolin]

Good evening,

today one of our fhgfs storage nodes was disassociated by a network card failure.

We repaired it and put it on line but the management server gave it a new ID.

Do you know if there is a procedure to reset the node to its old ID?

Sincerly yours,

Francesco
--
Francesco Zanolin

Istituto Nazionale di Geofisica e Vulcanologia
Centro Nazionale Terremoti
Servizi Informatici E Reti
Via di Vigna Murata 605
00143 Roma Italy

cell. 3346418320
tel: 0651860346 fax. 0651860541
e-mail: francesc...@ingv.it

[Sven Breuner]

Hi Francesco,

can you please give a few more details about what happened. In general,
the nodeID and the targetID is stored inside the storage directory.
That's why these IDs can't change as long as you're using the same
storage directory.

Is it possible that you used the storage server with a "new" storage
directory, e.g. because your RAID volume was not mounted when the
fhgfs-storage daemon started and thus the daemon was started with an
empty storage directory?

If this is the case, then:

a) There is a safety option "storeAllowFirstRunInit" in the config files
of the fhgfs server daemons that you should set to "false" to make sure
they cannot be started with an empty storage directory.

b) "fhgfs-ctl mode=listtargets" can be used to show the registered
targetIDs each server (and you'll find the corresponding targetID file
in every fhgfs storage directory);
"fhgfs-ctl mode=unmaptarget" can be used to remove a registered targetID
from the management daemon, "fhgfs-ctl mode=removenode" can be used to
remove a registered node from the management daemon.

c) If you really created a new target and even stored files on it, which
you would like to keep, you would need to run the fhgfs-storage daemon
with both (the orginal and the new/unwanted target) and could then use
"fhgfs-ctl mode=find" or "fhgfs-ctl mode=migrate" to either identify the
files on the unwanted target or to migrate those files to the other
targets, so that you can safely remove the unwanted target afterwards.

Best regards,
Sven Breuner
Fraunhofer

[Francesco Zanolin]

Il 05/03/2012 23:06, Sven Breuner ha scritto:
> Hi Francesco,
>
> can you please give a few more details about what happened. In general,
> the nodeID and the targetID is stored inside the storage directory.
> That's why these IDs can't change as long as you're using the same
> storage directory.
>
> Is it possible that you used the storage server with a "new" storage
> directory, e.g. because your RAID volume was not mounted when the
> fhgfs-storage daemon started and thus the daemon was started with an
> empty storage directory?

Hi Sven,

An heartfelt thanks for the reply,

I turned off the service fhgfs-storage on the node, restart it once the
disk is exported and after i removed the targetId solving the problem.

Sincerely yours

Francesco

P.s. Our fhgfs system is running on five servers (1 manager, 2 metadata,
5 storage) and one Equallogic PS6500 with 42TB(eff. 35TB in five 5TB
slices) exported via ISCSI on a gigabit lan.

[Sven Breuner]

Hi Francesco,

thanks for the feedback and for your system description - it's always
interesting for us to learn about how and on which hardware people use
fhgfs out in the field.

Best regards,
Sven