Q: since "autofs" is not working properly on SLC6 - how stable is 'eosxd' on SLC6 compared to CC7?
A (APeters): same stability, but on SLC6 it's basically autofs which cannot unmount the unused FS... still under investigation
A (BJones): some problems might not be  spotted on CC7, as there is not enough batch capacity on CC7

C: (EObreshkov) ATLAS is still using a lot SLC6, and will use containers with SLC6... struggling to find out why the EOS-FUSE is not stable in the containers

Q: LDeniau: the "bad example" is used by BE-ABP: ROOT "hadd()" and CONDOR batch jobs, writing many files in a single dir - what to expect?
A (APeters): Try to split over several directories to reduce crosstalk. Try not to use SQLite, if possible or use it only for reading, as writing generates a lot of flock()s; for boosting performance we can try to relax the messaging for each file written
A (Ben): In batch, the default use case is in sandboxes (the input data is loaded, processed and then copied into the shared FS)
A (Jan): see already-existing (AFS-area) best practices for using the shared FS

Q (APfeiffer): Can you do a "make -j 20" from a single machine?
A (APeters): In principle yes, at ~the same speed as AFS; has been tried with -j 4... just because the machine didn't have enough cores; question about why would you run the compilation on the shared FS
A (APfeiffer): output is needed on a shared FS
A (Jan): temporary object files might go outside the shared FS (as best practice - EOS should still work OK, just become slow)

Q: Why do you not recommend to use EOS for the home directories yet?
A (APeters): still some known issues to be fixed before this is made more widely available
A (Jan): nothing major, just that we would like not to waste user's time on things we already know that can be improved before making it widely available
Comment: testing the new EOS FUSEX is important for many users, and could easily become a show-stopper if not done in time

Q: What would be the difference between AFS and EOS, provided all things are fixed?
A (APeters): feature-wise, almost on par; high throughput would be more easily achievable; some things would be slower, due to the fact that eosxd runs in user space (high I/O operations would be slower than on AFS, due to the architecture fuse vs in-kernel)
A (Jan): specific AFS workloads (if using AFS commands, not just filesystem) would need to be translated

Q (APfeiffer): Do you plan long term to have a kernel interface for the EOS client?
A (APeters): due to kernel conservative approach to kernel releases in RHEL/CentOS, we might not want to take this approach

Q (APfeiffer): Would it be possible to push it as a kernel module in order to eliminate part of the performance issues?
A (Jan): Strict kernel policies may prevent for the module to be accepted in mainline. Also fragile interface - contributes to current AFS trouble.

Q: Are 24h backups available?
A: Yes, in a slightly different way; we have the recycle in which we keep removed data for 6 months
A: No tape backup at the moment, and not envisaged; R&D for having snapshots running every day

Q: Can a directory be recovered completely?
A (APeters): Yes, if removed in one go via "rm -r"; we keep versions for files, as well
A [clarification after meeting]: note: FUSE/FUSEX do not create versions for every open/update/close - see  EOS-3194