Hi, Daire Byrne: > Is it possible (or even sane) to configure aufs2 to never read or stat > data in a lower branch to check if it is newer/modified? I have a > small subset of files on a local filesystem which have been copied off > a remote NFS filesystem. When accessing the local files I would like > to avoid going across the network and checking if those files have > been modified. Everything is read-only so I don't care about > white-outs or copyups. So if the file exists in my local "cache" then > never look at the second branch which is on a slow high latency > network link - if the stat/read of the file returns from the top > branch don't bother check the next branch. > > I am looking to create a cache of commonly used read-only data but > with an underlying NFS filesystem which we resort to only if it is not > in the local cache. The problem now is that aufs still goes to the > network even if the files are in the top (local) branch.
Let me make sure, - you have two branches - the upper branch is a local filesystem, commonly used one instead of exotic rare fs - the lower is NFS - the target is a regular file, instead of a directory When "fileA" exists on both of two branches and you access it through aufs, you observed aufs accesses the lower fileA on NFS. If so, that is weird. Give me these info. ---------------------------------------------------------------------- - /proc/mounts (instead of the output of mount(8)) - /sys/module/aufs/* - /sys/fs/aufs/* (if you have them) - /debug/aufs/* (if you have them) - linux kernel version if your kernel is not plain, for example modified by distributor, the url where i can download its source is necessary too. - aufs version which was printed at loading the module or booting the system, instead of the date you downloaded. - configuration (define/undefine CONFIG_AUFS_xxx) - kernel configuration or /proc/config.gz (if you have it) - behaviour which you think to be incorrect - actual operation, reproducible one is better ---------------------------------------------------------------------- J. R. Okajima ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
