- Compact style
- Indico style
- Indico style - inline minutes
- Indico style - numbered
- Indico style - numbered + minutes
- Indico Weeks View
Slow upgrade of FSTs running on EOSPUBLIC ongoing (to 4.1.29).
EOSALICE is on 4.1.30, EOSLHCB on 4.1.31 (supposed to fix a FSCK crash but does not - ongoing investigation into "ghost" FS).
EOSATLAS (mail about disappearing file) - need to recover (re-register in namespace) the files that have gone due to the balancing bug (need to recover logfile from CASTOR)
Update planned for Oct 10th (CERNBox web service, not EOS)
EOS: need to compact, need to validate & eventually deploy newer EOS.
CERNBox (web) - being puppetized (Hugo)
EOS MGM: logrotate (copy+truncate) causes hiccups ("D" state) - need to look at alternatives:
QA for 4.1.30 didn't show any issues, so it was tagged for production yesterday: CRM-2426
4.1.30 has also been tagged in the eos7-pending tag, which means LinuxSoft will pick it up for their next desktop updates cycle.
The eosclient puppet module has a small improvement in qa: CRM-2437
Around half of EOSPPS' diskserver are now running Centos7.
Improvements regarding SystemD support will be pushed to EOS in the coming days.
old EOS nodes will get re-used for SWAN test before being retired.
BE (meeting) 2017-09-25: BE would like SWAN to be a production service, with SPARK adapter.
FUSEX code has been carved out of the Aquamarine GIT repo into:
https://gitlab.cern.ch/eos/eos-fusex/
It is now included into Citrine & Aquamarine as a sub-module.
[submodule "fusex"]
path = fusex
url = https://:@gitlab.cern.ch:8443/eos/eos-fusex.git
branch = master
Joszef is adding it to the Citrine master build pipeline in GitLab, I am adding it to the Aquamarine build in Jenkins. Once build succeeds, create new RPM eos-fusex containing eosxd.
The server side implementation is currently only available in the Aquamarine code (initial testing will be on EOSUAT instance). Elvin can start the merging into Master when he is back [ it is slightly more complicated to do that because of namespace API changes]. First version containing server side support will be EOS Aquamarine 0.3.270. Both MGM and FST need to be updated for new functionality.
We are still fixing both builds.
If a client mounts an instance with a different fusex protocol version, it receives an evict message (e.g. unmount).
Quota Interface via mount point
[root@eos-aufs fuse]# getfattr --only-values -n eos.quota /eos/dev/fuse/
getfattr: Removing leading '/' from absolute path names
instance uid gid vol-avail ino-avail max-fsize endpoint
dev 99 99 7269240152 997505 549755813888 apeters.cern.ch:1094
The quota status on client side is not yet real-time enough. FUSE clients sees only changes of a quota node, where they currently has a CAP. There is a regular update done by listing or max. after 5 minutes. Need to add a server side quota node push if an authenticated ID runs out of quota.
A flush call from one FUSE client triggers a cache invalidation on all other clients having a file open. E.g. cache invalidation happens also while filedescriptors are already open.
O_SYNC
open(...O_SYNC) disables the local file start cache/journaling. For large file uploads this gives better throughput.
FSYNC
Synces everything from the local journal and it is guaranteed that clients see the updated contents in that moment. fsync calls internally the flush logic as explained above.
After some back and forward Georgios has found a 'solution' to avoid the need of eosfusebind. He can explain best. When his work is finished he needs to register his new class in a single function:
class fusexrdlogin {
public:
static int loginurl ( XrdCl::URL& url, fuse_req_t req ,
fuse_ino_t ino,
bool root_squash = false,
int connectionid = 0);
};
The async ZMQ connection does not fail-over automatically on master slave redirection.
Rollout:
Giorgios is waiting for a "testbed"? Might be EOSUAT (but will not get new namespace), EOSBACKUP will get new namespace but needs to go to "citrine" first, also needs an additional node ( could use a 32GB VM with local SSD (not throttled)?).
Updated Samba (from CC74), this messed up the not-quite-production workflow for video conversion. Also not-understood disconnects.
(mail from Michal, "FYI"):
Should ask CERN security team for help/audit. Also should discuss whether we enable "request signing" (available in 4.7) - enforce between MGM and FST, optional for clients (new clients will be protected against request hijacking)?
Tests to AARNET from EOSUAT - achieved 50Gb; bottleneck is inside network.