14. September 2015: CernVM-FS 2.2.0 Server Only Pre-Release

A patch release for the server anticipating upcoming version 2.2.0 is out. Please find the release notes on a separate page.

31. March 2015: CernVM-FS 2.1.20

Release CernVM-FS 2.1.20 is out.  Please find the release notes on a separate page.

27. May 2014: CernVM-FS 2.1.19

Release CernVM-FS 2.1.19 is out.  Please find the release notes on a separate page.

10. March 2014: CernVM-FS 2.1.17

Bugfix and consolidation release CernVM-FS 2.1.17 is out.  Please find the release notes on a separate page.

10. October 2013: CernVM-FS 2.1.15

Note: CernVM-FS 2.1.15 has not yet been fully validated by WLCG (see CernVM-FS release procedure).  The recommended version in WLCG is CernVM-FS 2.1.14 until further notice.
Update 17.10.2013: CernVM-FS 2.1.15 is now the recommended version for all WLCG sites.

CernVM-FS 2.1.15 contains bug fixes and new features. Updating from 2.1.14 works through an RPM upgrade assisted by the CernVM-FS hotpatching feature. For updating from version 2.0.X, please read the notes down this page.  For all upgrades, we recommend to upgrade in stages starting with a small fraction of worker nodes first followed by a ramp up if there are no problems.

For stratum 0 installations, this release has to migrate existing repositories in order to make a small modification to the catalog schema (backwards compatible).  Please backup your stratum 0 repositories before upgrading.

Changes and Improvements

  • Updated external dependencies: libcurl 7.32.0, c-ares 1.10.0, zlib 1.2.8, sqlite 3.7.17, leveldb 1.12.0
  • Client: release pinned catalogs at high watermark of pinned files (37.5% of the overall cache size).  See Savannah.
  • Client: automatically unmount a crashed mountpoint in order to recover from crashes (no stalled mountpoint in "Transport endpoint not connected" state); see Savannah
  • Client: experimental support for WLCG proxy auto-discovery through the "auto" keyword in CVMFS_HTTP_PROXY; see WLCG proposal and Savannah
  • Client: reduce memory fragmentation of the inode tables shadowing kernel tables
  • Client: experimental support for cvmfs_talk pin command to manually pin files
  • Client: experimental support for local mapping of user ids and group ids; CVMFS_UID_MAP and CVMFS_GID_MAP can point to ASCII files of linewise mappings <upstream id> <local id>
  • Client: enforce hard limit (16) on the number of concurrent HTTP connections
  • Client: use User-Agent header instead of X-CVMFS2 header to indicate the cvmfs version to a server; this re-establishes the behavior of the 2.0 client
  • Client: additional checks in cvmfs_config chksetup for
    • accessibility of /etc/nsswitch.conf
    • overall size of cache partition compared to CVMFS_QUOTA_LIMIT
  • Client: redirect SQlite exceptions to the cvmfs logger
  • Client: place SQlite temporary files into cache directory
  • Client: switch from from fuse4x to OSXFuse on Mac OS X;  fuse4x is not maintained anymore and it is superseded by OSXFuse
  • Server: experimental support for repository tags (named snapshots); this feature allows to mount a specific repository version and to rollback and re-publish previous repository states
  • Server: new cvmfs_server import command to migrate a 2.0 repository to a 2.1 repository
  • Server: experimental support for overlayfs as an alternative to aufs
  • Server: allow to create a replica with a local alias name;  this can be used, for instance, to host stratum 0 and stratum 1 on the same server
  • Server: support multi-repository operations and wildcards in cvmfs_server commands
  • Server: new repositories are replicatable by default
  • Server: increase default expiration time for .cvmfspublished to 2 minutes in order to avoid being dDoS'd by misconfigured Squid
  • Server: improve logging when a publish operation fails due to insufficient permissions; see Savannah

Bug Fixes

  • Client: fix unpinning of catalogs on unmount; this ensures that unmounted repositories do not leave pinned garbage in the shared cache
  • Client: fix rare inconsistency in runtime size tracking of the pinned elements in the cache
  • Client: fix false negative caching of I/O errors that occur during path lookup; see Savannah
  • Client: fix various issues when reading chunked files
  • Client: fix listxattr system call by removing trailing empty attribute
  • Client: fix option parsing of config files without a trailing newline
  • Client: fix potential endless loop in HTTP I/O thread
  • Client: treat all HTTP 5XX errors as host errors, not as proxy errors
  • Client: fix error classification of local I/O errors during download; see Savannah
  • Client: fix fail-over counter and prevent cvmfs from failing-over more often than the total number of hosts / proxies
  • Client: properly handle (ignore) mount options auto, noauto, user, nouser, users, _netdev
  • Client: fix detecting the service utility under Ubuntu in cvmfs_config
  • Client: fix round-trip time calculation in cvmfs_talk host probe
  • Client: unset executable bit of /etc/cvmfs/{default.conf,config.sh}
  • Server: fix occasional crashes in cvmfs_server publish due to a race

13. August 2013: CernVM-FS 2.1.14

Note: do not use version 2.1.13.
CernVM-FS 2.1.14 is a security hotfix release.  Due to missing option sanitizing in the /etc/auto.cvmfs script, normal users can escalate their permissions through the automounter and become root.

The hotfix adds option sanitation to /etc/auto.cvmfs.  This fix can be applied without service interruption.  The options are:

  1. Manually exchange /etc/auto.cvmfs by
    https://ecsft.cern.ch/dist/cvmfs/cvmfs-2.1.14/auto.cvmfs
  2. By upgrading the cvmfs RPM.  Note that although there are no other changes compared to cvmfs 2.1.12, the RPM post-install script will still reload the Fuse module.  There is a small, but non-zero chance that the reload might disrupt operations.

Please apply the fix as soon as possible.  Please also check your CernVM-FS clients for suspicious setuid binaries.  We consider this as hotfix and there will be a more careful review of the mount helpers for the next release of CernVM-FS.

24. July 2013: CernVM-FS 2.1.12

CernVM-FS 2.1.12 has been released. This is a bugfix release. Updating from 2.1.11 works through an RPM upgrade assisted by the CernVM-FS hotpatching feature. For updating from version 2.0.X, please read the notes down this page.

This release has been tested in production at a Tier 1 site for one week (cf. http://cernvm.cern.ch/portal/filesystem/release-procedure). Nevertheless, upgrading in stages is recommended.  Start with only a few worker nodes and upgrade gradually.

Bugfixes and Improvements

  • Fix stratum 1 fail-over of proceed connections: if a proxied network connection breaks or times out, previous 2.1.X versions would always blame the proxy and not try to fail-over the host. In the course of fixing this issue, a write-up of the cvmfs fail-over logic has been published: http://cernvm.cern.ch/portal/filesystem/failover
  • Fix timeout reset for NFS shared maps
  • Fix help text of cvmfs_talk
  • Improves the speed of cvmfs_config reload
  • Replication: safe guard against concurrent snapshot processes
  • Drop dependency on config.sh (part of the client) from cvmfs_server

24. June 2013: CernVM-FS 2.1.11

CernVM-FS 2.1.11 is released.  It is a bugfix and consolidation release.  Version 2.1.11 supersedes all previous releases and is the recommended release for new and existing users.  Updating from 2.1.10 works through an RPM upgrade assisted by the CernVM-FS hotpatching feature.  For updating from version 2.0.X, please read the notes down this page.

This release has been tested at two Tier 1 sites for a few weeks.  Nevertheless, upgrading in stages is recommended.  Start with only a few worker nodes and upgrade gradually.

Bugfixes and Improvements

  • Fix host failover
  • Fix cvmfs_config reload on 32bit systems
  • Fix build system and source RPM for SLES11
  • Fix occasional hangs of gdb when generating stack traces
  • Add CVMFS_MOUNT_RW parameter.  Mounting CernVM-FS in read/write mode can work-around dubious open() flags, such as described here: http://cern.ch/go/ssn8
  • Add missing execmod SELinux exception for 32bit SL6
  • Distinguish information, error, and warning records when logging to syslog
  • Improve host / proxy failover logging ("from <host> to <host>")
  • Improve logging on whitelist verification errors
  • Add automatic network path reset for host failover

21. May 2013: CernVM-FS 2.1.10

CernVM-FS 2.1.10 is released.  It fixes a serious problem found at RAL for the non-NFS mode: catalog updates (which happen at arbitrary points in time) under high load can trigger high load in the kernel, which substantially slows down the node for minutes up to hours.  This behavior is triggered by a specific pattern of issuing inodes used by CernVM-FS, which makes the kernel re-validate large portions of the directory tree.  The pattern has been replaced in this release.
Note on hotpatch: As this release makes changes to the low-level file system interface, hotpatching from previous versions is likely to fail.  The recommended way of upgrading is to drain the node.

The upgrade recommendation is:

  • New users and existing users of the 2.1 branch in non-NFS mode: use 2.1.10
  • Users of the 2.0 branch: upgrade in stages.  Start with only a few worker nodes for a few days, expand to a more substantial fraction of the cluster for at least a week before upgrading all nodes.
  • Users of the 2.1 NFS mode: optional upgrade, test for at least a week before upgrading the production NFS servers

Bugfixes and improvements

  • Ensure unique inode to path relationship during kernel-imposed lifetime of inodes.  This avoids multiple inodes for the same path and avoids large hangs of 100% system load. Many thanks to Ian Collier, Alastair Dewhurst, and John Kelly for reporting and for the help in debugging the issue!
  • Fix stack trace generation in the crash handler for the shared cache manager.  Many thanks to Bockjoo Kim for reporting!
  • Fix potential endless loop in the crash handler
  • Fix deadlock in cvmfs_config reload when the current working directory is on CernVM-FS
  • Fix cvmfs_config reload -c (reload with wiping out the cache) in case the cache directory is not owned by the cvmfs user
  • Fix potential erroneous re-use of directory handles after cvmfs_config reload
  • Prevent the build system from picking up an incompatible snappy library from the system
  • Add 'evict' command to cvmfs_talk in order to remove specific files from cache
  • Improve logging of I/O errors when updating the local cache database

This release has been running on pre-production nodes for several days.  This is part of the CernVM-FS release procedure that has been recently defined.  The release procedure will be published separately.

23. April 2013: CernVM-FS 2.1.9

CernVM-FS 2.1.9 is released.  It checkpoints many bugfixes and improvements, many of them critical fixes.  The upgrade recommendation is:

  • New users and existing users of the 2.1 branch in non-NFS mode: upgrade to 2.1.9
  • Users of the 2.0 branch: upgrade in stages.  Start with only a few worker nodes for a few days, expand to a more substantial fraction of the cluster for at least a week before upgrading all nodes.
  • Users of the 2.1 NFS mode: test for at least a week before upgrading the production NFS servers

Upgrading from CernVM-FS 2.1.8 is supposed be a hotpatch just by installing the new RPM.  Hotpatching can be also done manually by cvmfs_config reload. The bugfixes related to the inode handling are only effective after a full remount.

Bugfixes and improvements for the client

  • Fix the handling of inodes in order to avoid spurious "no such file or directory" errors.  Many thanks to Di Quing, Andreas Nowack, Barbara Krasovec, Ake Sandgren, and others for the help and patience during debugging!
  • Fix download failures when a download is retried on a half-finished chunk.  Many thanks to Ake Sandgren for reporting!
  • Fix potential endless loop in the automatic cache cleanup routine.  Many thanks to Dmitry Ozerov for reporting!
  • Fix a race in the unloading and loading of the shared cache manager that can be triggered by quickly unmounting and mounting
  • Fix save and restore of the counters for the number of open directories and the number of open files during reload
  • Add SELinux exceptions in order to support stacktrace generation and reloading on SL 6.4
  • Fix of several memory and file descriptor leaks
  • Fix potential race when reloading a new file system snapshot
  • Fix handling of the -n option in the mount helper
  • Log to syslog when a new revision of the file system is loaded
  • Added new CVMFS_NFS_SHARED option to enable SQLite for NFS inode mappings.  This allows the inode database to be placed on shared storage and accessed by multiple CernVM-FS NFS export nodes simultaneously for clustering (see below).
  • Omit misleading autofs warning of cvmfs_config chksetup in NFS mode
  • More readable output of cvmfs_config reload
  • Improve logging to syslog for whitelist verification errors
  • Swtich to SQLite 3.7.16.2
  • Include pretty-printed stack traces in the bugreport tarball
  • Recognize CVMFS_IPV4_ONLY environment variable and, if set to a non-empty value, avoid the use of IPv6 addresses

Bugfixes and improvements for the server toolkit

  • Fix removal of temporary files during replication
  • Fix handling of SELinux context on SL5
  • Fix handling of the log level parameter in cvmfs_server snapshot
  • Added "pause mode" to cvmfs_server publish in order to allow for manually fixing file catalogs
  • Recognize http_proxy environment variable for replication
  • Perform catalog updates asynchronously to the hashing and compression of files when publishing

Shared NFS Maps (HA-NFS), contributed by Simon Fayer

As an alternative to the existing, leveldb managed NFS maps, the NFS maps can now optionally be managed by SQlite.  In order to do so, set CVMFS_NFS_SHARED=<path>.  This path can be hosted on a shared file system which has to support POSIX locks.  At the cost of performance, two NFS servers exporting CernVM-FS file system can share the NFS maps and provide consistent path to inode mappings.

7. March 2013: CernVM-FS 2.1.8

CernVM-FS 2.1.8 is released.  It contains the following changes and fixes:

  • Fix: faulty evaluation of variant symlinks could lead to empty or 1-byte symlinks
  • Fix: the debug log of the shared cache manager has been mistakenly written to the cache directory
  • Fix: cvmfs_config chksetup on Mac failed to find the libcvmfs_fuse shared library
  • Fix: the crash handler could fail to gather stack traces due to missing ptrace() permissions
  • Use 32bit inodes by default, required for compatibility with 32bit software on 64bit platforms
  • Added SElinux exception to allow for reloading of the CernVM-FS fuse module
  • Run default signal handler after handling a crash
  • Optional support for ignoring cross-directory hardlinks in the server toolkit (instead of aborting the publish operation)

Upgrading from CernVM-FS 2.1.7 is supposed be a hotpatch just by installing the new RPM.  Hotpatching can be also done manually by cvmfs_config reload. The crash handler will only produce proper stack traces once CernVM-FS is remounted on the new version.

22. Feburary 2013: CernVM-FS 2.1.7

CernVM-FS 2.1.7 is released.  It contains a number of important bugfixes:

  • Fix: improper handling of inodes could result in corrupted data being served from the file system kernel caches after a reload of the file catalogs.
  • Fix: the client used wrong link counts for 2.0 repositories
  • Fix: the mount helper could return unexpected error codes, resulting in misleading error messages such as "too many symbolic links" in case of mount problems
  • Fix: the watchdog was unable to resolve symbol names in stack traces
  • Fix: private mount points listed in /etc/fstab could result in a deadlock during system boot
  • Fix: due to a missing dependency in the build system, parallel builds could fail
  • Fix: cvmfs_server snapshot did not correctly store the repository certificate
  • Fix: the CernVM-FS server toolkit could set wrong permissions on files in the backend storage
  • cvmfs_config reload does not cause error messages when updating from CernVM-FS 2.0.X
  • Improved error reporting to syslog on mount failures
  • Renamed cvmfs-lib RPM to cvmfs-devel
  • Multi-threaded storage backend
  • Changed default installation prefix to /usr
  • Added support for a new parameter CVMFS_KEYS_DIR: instead of listing all public signing keys specifically in CVMFS_PUBLIC_KEY, CVMFS_KEYS_DIR allows the specification of a directory from which all *.pub files are taken as valid repository sigining keys. Defaults to /etc/cvmfs/keys.

Upgrading from CernVM-FS 2.1.6 is supposed be a hotpatch just by installing the new RPM.  Hotpatching can be also done manually by cvmfs_config reload. In order to upgrade a repository created with CernVM-FS 2.1.6, use cvmfs_server migrate


CernVM-FS 2.1 Changes and New Features

Source code: https://github.com/cvmfs/cvmfs
Packages: https://ecsft.cern.ch/dist/cvmfs/
Developers' mailing list: cvmfs-devel@cern.ch

Upgrading from 2.0.X

On a cluster of machines, CernVM-FS versions 2.0 and CernVM-FS 2.1 can happily coexists.  As usual, we suggest a smooth upgrade procedure starting with only a few nodes and, if successful, gradually upgrading the rest of the nodes.

Please note that the recommended way to upgrade CernVM-FS on a single machine is to remove version 2.0.X and to re-install 2.1 in the following steps

  • Drain the worker node from jobs accessing /cvmfs/...
  • Remove the cvmfs rpm
  • Manually delete the cache directory (CVMFS_CACHE_BASE in /etc/cvmfs/default.local or /etc/cvmfs/default.conf)
  • Install the cvmfs 2.1 RPM
  • If the cvmfs configuration is not done by a central configuration management, such as Puppet or Chef, run cvmfs_config setup
  • Keeping in mind that version 2.1 uses a shared cache by default, re-check the setting of CVMFS_QUOTA_LIMIT.  In most cases, a limit of 20000 (20G) is sensible

If draining the nodes is not an option, at least the cache directory has to be changed.  As long as there are mounted 2.0 instances, the behavior of the CernVM-FS auxiliary tools cvmfs_config and cvmfs_talk are undefined.

Changes

  • Default location of the cache directory moved to /var/lib/cvmfs
  • The SystemV init script has been removed, its commands (probe, restartclean, ...) have been moved to cvmfs_config
  • For consistency reasons, cvmfs-talk has been renamed to cvmfs_talk
  • Signed catalogs are required by default
  • libfuse is linked dynamically
  • Switched back from jemalloc to standard glibc malloc

New Features

Mac OS X Support

On Mac OS X, CernVM-FS is based on Fuse4X (http://fuse4x.github.com). It is not yet integrated with autofs. The following steps mount the CMS repository:

  1. Create /etc/cvmfs/default.local and add CVMFS_HTTP_PROXY=DIRECT
  2. sudo mkdir -p /cvmfs/cms.cern.ch
  3. sudo mount -t cvmfs cms.cern.ch /cvmfs/cms.cern.ch

Shared Local Harddisk Cache

The shared local harddisk cache allows to set common cache quota for a set of repositories (e.g. "the cache volume used by all my repositories should not exceed 20G"). Repositories connected to the shared cache manager use "$CVMFS_CACHE_BASE/shared" as cache directory (instead of, e.g., "$CVMFS_CACHE_BASE/cms.cern.ch"). Repositories that use the shared cache manager and repositories that use an exclusive cache can be safely mixed. The cache size limit (CVMFS_QUOTA_LIMIT) applies to the shared cache as a whole. Individual repositories cannot be given a fixed share of the cache.
Note: the shared cache is enabled by default for all repositories.  The shared cache can be turned off globally or by repository by setting CVMFS_SHARED_CACHE=no in /etc/cvmfs/default.local or /etc/cvmfs/config.d/<repository>.local, respectively.

The shared cache manager is not another binary but the cvmfs2 process forks to itself with special arguments, indicating that it is supposed to run as a cache manager. The cache manager does not need to be started as a service. The first cvmfs instance that uses a shared cache will automatically spawn the cache manager process. Subsequent cvmfs instances will connect to the pipe of this cache manager. Once the last cvmfs instance that uses the shared cache is unmounted, the communication pipe is left without any writers and the cache manager automatically quits.

The cvmfs_talk command pid cachemgr shows the process id of the shared cache manager.  If the exclusive cache is used, it is the same as the pid command.

NFS Export

NFS export requires Linux kernel >= 2.6.27 on the server. It works for SL6 but not for SL5. NFS clients can run both SL5 and SL6.

For proper NFS support, set CVMFS_NFS_SOURCE=yes in /etc/cvmfs/default.local. When this mount option is enabled, upon mount an additionally directory nfs_maps.$repository_name appears in the cvmfs cache directory.

For decent performance, the amount of memory given to the meta-data cache should be increased. By default, this is 16M. It can be increased, for instance, to 256M by setting CVMFS_MEMCACHE_SIZE=256 in /etc/cvmfs/default.local

Some details about the "NFS maps": The cvmfs file catalogs are structured along the directory tree and inodes are artificially generated. On a local machine, cvmfs has control over caches and can avoid stale inodes. With NFS export, however, a once issued inode can be asked for anytime later by a client. To be able to reply to such client queries, the cvmfs "NFS maps" implement a persistent store of the path names -- inode mappings. Storing them on hard disk allows for control of the cvmfs memory consumption (currently ~45M extra) and ensures consistency between remounts of cvmfs. The performance penalty for doing so is manageable. Cvmfs uses Google's leveldb, a fast, local key value store. Reads and writes are only performed when meta-data are looked up in SQlite, in which case the SQlite query supposedly dominates the running time.

There is no easy way to account for the NFS maps storage by the cache quota. According to first experiments, they sum up to some 150-200 Bytes per path name that has been accessed. A recursive 'find' on /cvmfs/atlas.cern.ch with 25 million entries, for instance, would add up 5G in the cache directory. This should be still tolerable as the NFS mode will be only used on few servers that can be given large enough spare space on hard disk.

Sample /etc/exports:
/cvmfs/atlas.cern.ch 172.16.192.0/24(ro,sync,no_root_squash,no_subtree_check,fsid=101)
Sample /etc/fstab entry on clients (NFSv3):
172.16.192.210:/cvmfs/atlas.cern.ch /cvmfs/atlas.cern.ch nfs nfsvers=3,noatime,ac,actimeo=60 0 0

Hotpatching / Reloading

By hotpatching a running CernVM-FS instance, most of the code can be reloaded without unmounting the file system.  The current active code is unloaded and the code from the currently installed binaries is reloaded.  Hotpatching is logged to syslog.  Since CernVM-FS is re-initialized during hotpatching and configuration parameters are re-read, hotpatching can be also seen as a "reload".

Hotpatching has to be done for all repositories concurrently by
cvmfs_config [-c] reload
The optional parameter -c specifies if the CernVM-FS cache should be wiped out during the hotpatch.
Reloading of the parameters of a specific repository can be done by, e.g.
cvmfs_config reload atlas.cern.ch
In order to see the history of loaded CernVM-FS Fuse modules, run
cvmfs_talk hotpatch history
The currently loaded set of parameters can be shown by
cvmfs_talk parameters

Technically, the hotpatch functionality is implemented using a loader process (cvmfs2) and a shared library containing the actual Fuse module (libcvmfs_fuse.so).  The loader process implements stub Fuse callbacks that redirect all calls to the cvmfs shared library.  Hotpatch is implemented as unloading and reloading of the shared library, while the loader temporarily queues all file system calls in-between.

As of CernVM-FS 2.1.5 the RPM package will use hotpatching to update CernVM-FS.

Adjustable Syslog Facility

The syslog facility used by CernVM-FS can be set to LOCAL0..LOCAL7.  To do so, set the CVMFS_SYSLOG_FACILITY to 0..7. An unset value is interpreted as the default USER facility.

Performance Counters

A number of performance counters can be gathered online from cvmfs by running
cvmfs_talk internal affairs

Server Tools

The CernVM-FS server tools have been rewritten from scratch. The new backend has two main purposes

  1. Based on a union file system, avoiding the need for a separate read-write copy of a repository. Changes and updates are written to the scratch area of the union file system and from there directly committed to the cvmfs repository.
  2. Decoupling of the file catalog updates and the processing of files (compressing, hashing). This is done by a "spooler". New and modified files are handed over to a separate spooler process. The spooler processes files and uploads them to final storage. Currently, there is only a very simple spooler implemented that uses a local directory as backend storage.

Note: SL6 needs a patched kernel in order to support the aufs kernel module.  SL6 kernels with aufs as well as the aufs user space utilities can be found here: https://ecsft.cern.ch/dist/cvmfs/kernel

Hardlinks

Hardlinks are emulated in the new server. There is support for regular file and symlink hardlinks provided that both links are in the same directory. This is the only case where hardlinks appear in LHC software (such as cc and gcc).

The usual directory "hardlinks" are supported, where the "." and ".." are seen as hardlinks. Essentially, directories know how many sub directories they have.

Consistency Check

The old cvmfs_clgcmp has been replaced by cvmfs_check. The cvmfs_clgcmp doesn't make any sense anymore because there is no authoritative read/write copy against which the catalogs can be compared. Instead, cvmfs_check is a meta-data sanity check. It recursively walks through the repository and checks, for instance, that referenced SHA-1 chunks are present, that hardlink counters are correct, that there are no dangling entries, the integrity of the transition from parent to nested catalogs, and so on. It's meta-data only, it won't re-hash the data chunks.

New Features

  • Support for multiple repositories on the same host
  • Support for Stratum 0 and Stratum 1 repositories on the same host
  • Support for custom scripts before and after publishing operations (/etc/cvmfs/cvmfs_server_hooks.sh)
  • The uid and gid is stored. That allows for POSIX access checks. At the cost of a few percent in performance, access checks can be enabled in the client by CVMFS_CHECK_PERMISSIONS=yes.
  • CernVM-FS learned how to count. The idea is that the catalogs know how many entries there are in their sub catalogs even without opening them. This way, you can immediately tell how many entries, for instance, the entire ATLAS repository has. The numbers are shown using the number of inodes in statvfs. So df -i shows the overall number of entries in the repository and (as number of used inodes) the number of entries of currently loaded catalogs. Nested catalogs create an additional entry (the transition directory is stored in both the parent and the child catalog). File hardlinks are still individual entries (inodes) in the cvmfs catalogs.
  • There is schema support for the chunking of files. It is not yet supported by the code though.

To be done

  • Additional/improved spooler implementations. For the local file system backend, a spooler that uses multiple threads for compression and hashing. An additional spooler for the Riak key-value store.
  • Client support for uid/gid mapping

Internal Affairs

  • Asynchronous HTTP I/O using poll() in a separate I/O thread
  • Locking is much more fine-grained. Instead of one big meta-data mutex, there are independent mutexes for all the cache layers and catalogs. This results in better scalability on multi-core machines.
  • A custom string class allocates most of the memory of path strings on the stack
  • The expiry of the catalog TTL is now handled by an alarm. This avoids calling gettimeofday() in every stat() operation.
  • The quota module is able to process file opens and file inserts in bunches (currently: 32 files/bunch). All the open/insert operations of one bunch are processed in a transaction on the underlying SQlite cache database, instead of one-by-one processing. On the plus side, it improves speed if many files are opened. On the negative side, strict LRU semantics is lost, as in some cases recently opened files, that happen to sit in a not yet processed bunch of files, might be removed by the cache cleanup procedure

You are here