Skip to content

EOS spaces versus disk storage layouts

The configuration of EOS disk layouts maybe directory oriented and not EOS space oriented as is required by an EOSCTA instance such as ALICE. This section describes the problem which will hopefully be fixed in the future.

EOS spaces are orthogonal to EOS directories and files. An EOS file with a given EOS path can be stored on different EOS spaces during its lifetime. The EOSCTA setup for the ALICE experiment in one such example. An SSD space will be used when the file is archived to tape and a mechanical hard drive space will be used when the file is retrieved back from tape.

Up until about a year ago EOS disk layouts were a property of a directory. All of the files within a directory would have the layout dictated by the directory. The configuration of a directory’s layout is stored in its extended attributes. Here is an example of a disk layout configuration for the EOS directory /eos/ctaalicero/spinners/raid6: 

[root@eosctafst0105 ~]# eos attr ls /eos/ctaalicero/spinners/raid6
sys.eos.btime="1587019877.260408836"
sys.forced.blockchecksum="crc32c"
sys.forced.blocksize="4M"
sys.forced.checksum="adler"
sys.forced.layout="raid6"
sys.forced.nstripes="10"
sys.forced.space="spinners"
[root@eosctafst0105 ~]#
Such a directory oriented configuration is incompatible with the EOSCTA requirement of being able to store files in a different way when they are being archived to tape and when they are being retrieved back from tape. The current idea for ALICE is that the SSD space be arranged in a single replica layout and the mechanical hard drive space be arranged in a raid 6 layout.

In theory the layout of an EOS space can in fact be configured for the space itself. The following URL gives the documentation of this space oriented configuration:

This configuration has yet to be proven to work. If it does work then this would enable an EOSCTA instance such as ALICE to be configured correctly.