Step to update to laster 5.x.x. version

Hello Elvin
at GRIF we are running on eos 5.1.22

we could update to 5.1.30 (before update to 5.2.x )
but how we enable the extended attribute on FSTs ?
how we could check that the conversion is finished on each FST ?

where we run eos-fmd-tool --log-level debug convert --fst-path /ourpool/disk01
the fs should be ro or not ?

thank you in advance

I can not find an example ( or procedure)
for the usage eos-fmd-tool ( for leveldb conversion and checking)

Hello Any update on those question ?
thank you in advance

Hi Emmanouil,

The best way to trigger the conversion is to bundle it with the upgrade to 5.1.30 or by doing a simple restart of the FST with the following entry in the /etc/ configuration file:
fstofs.filemd_handler attr

NOTE: this configuration directive needs to stay in the config file otherwise if you remove it and restart the FST it will default to using again LevelDB as the back-end for FMD info. Once you upgrade to 5.2.* this configuration can be dropped as LevelDB support was removed from 5.2.0 on.

The conversion of the entries will happen during the FST start-up phase. The node will not accept any new traffic (rd/wr) until the conversion is completed. Once the conversion is done, the file systems will boot and become available for rd/wr operations as usual.

You can check for the following log message in the FST logs that also prints with some performance counters:
conversion successful, set done marker

The conversion of one FST can take anywhere between a few seconds and up to 1 hour depending on the HW and number of files stored on that particular machine. In general, we’ve seen rates of up to 20kHz of conversions at CERN.

To avoid that any of the files are unavailable the usual precautions of updating the FSTs one by one still apply.


Hello Elvin

In one fst with 5 FS and approximately 60K files per FS
the /var/eos/md has around 55Mbytes

those number are expected ?

Yes, that’s sounds fine.


hello Elvin
thanks you for the info again
we pass without problem to 5.1.28 and ware the migration from leveldb to attr ?
but the metadata from leveldb where are stored on local fs again or in quarkdb ?
you speak about 20Hz rate of conversion but this is exotic for me if the system use the quarkdb ?
I am not very familiar with those scales
thank you in advance

Hi Emmanouil,

Yes, the metadata is not anymore stored in LevelDB but it is attached as an extended attribute to the individual physical files. You can easily see this by running the getfattr -d </data/path/to/file> and you should see a user.eos.fmd extended attribute. Eg

 getfattr -d /home/esindril/Eos_data/fst2/00000000/00000a2f
getfattr: Removing leading '/' from absolute path names
# file: home/esindril/Eos_data/fst2/00000000/00000a2f

The rate that I mentioned was for the actual conversion from LevelDB to extended attributes (QuarkDB is not involved is any of this), and this value is reported for each file system that is converted at the end of the conversion process in the logs of the FST process.

Hope this helps!

hello Elvin
thank for you reply
in addition on fst log
after the Conversion we see

log entry like
240514 09:12:10 time=1715670730.430128 func=ConvertFS level=INFO logid=static… tid=00007fb5497fa700 source=FmdConverter:182 tident= sec=(null) uid=99 gid=99 name=- geo=“” msg=“conversion successful, set done marker” count=68854 success_count=68834 frequency=1.89 kHz

one file each FileSystem ( partition)
but there is not any correspondence to the particular FileSystem (partion)
just in one FST I have 6 partions and after the succefull conversion I have six lines in the log with

… set done marker"

there is a way to map those log entries to a particular FS ?