Many thanks for the hints about aufs string constants! We should indeed use them.
> In cvmfs/aufs2-standalone.git, I can see some commits added. > > 0560b14 2012-11-09 only include extra aufs header in kernel-headers package > 093b886 2012-11-08 patch fix > 842b1c1 2012-11-08 added rhel6.3 kernel config patch > 73bf994 2012-11-08 rhel6.3 kbuild patch adjustment for fs/Makefile > 1980173 2012-11-08 patches for rhel6.3 kernel (signature of vfs_stat changed) > > Mainly they are for rhel build. > The last one (1980173) is touchig the aufs source file just to follow > the change made in linux-2.6.36. This is equivalent to the commit in > aufs2-2.6.git (and aufs2-standalone.git too in different commit). > > 3cafe1c 2010-08-20 aufs: for 2.6.36, the parameter of vfs_statfs() I think I tried to use aufs-2.1-36 directly but it failed for some other reason (I might remember seeing "workqueue" errors when compiling). Hm, do you think there is a way to stay more closely to the upstream repository? > Just out of curious, what people are using CVMFS? > And, in the future when you upgrade your kernel version, will you switch > to another unioning filesystem (unionfs, overlayfs, UnionMount...)? At the moment, cvmfs is used by high energy physics collaborations, in particular the major experiment collaborations at the CERN LHC. The Fuse module runs on virtual machines and physical worker nodes that are part of a distributed computing infrastructure, mostly the LHC computing grid (http://wlcg.web.cern.ch), but also, e.g., LHC@Home 2.0 volunteers (http://lhcathome.web.cern.ch/LHCathome/Physics). There, it replaces package managers and NFS shared software areas as means to distribute the data processing software. While there are many cvmfs clients, there is only a single point of adding / modifying the cvmfs file system tree. This is a special "writer's machine" where we use aufs to provide a writable interface on top of the read-only Fuse module. A cvmfs mount point is the read-only branch and a local scratch area is the read-write overlay. This way, we can make modifications to the the file system tree and use the scratch area to feed the changes back into the cvmfs internal format. The way it works is that a new software version is installed on the writer's machine and once all changes are made, the writable branch is traversed by a cvmfs utility that commits new and modified files into the cvmfs "repository". Such a repository contains the content-addressable chunks as well as SQlite file catalogs to storing the directory tree. Some more details are here: http://cernvm.cern.ch/portal/filesystem/techinformation and here: http://cernvm.cern.ch/portal/filesystem/publications. So far, we have been very happy with aufs. We have looked into other options a while ago. The funionfs fuse module was too slow and it failed with some use cases involving hard links. Out of the kernel level union file systems, aufs seemed to be the only one still maintained, as far as I remember. I'm a bit confused about union mounts. Although apparently favored by the kernel community, it looks to me that they are not (yet?) there. Cheers, Jakob ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
