Hello Alexandre, Alexandre Levavasseur: > The result is here : https://gist.github.com/Alex131089/560a1386dd756059e21b > . > > It does the same as fsck.mergerfs for the permissions (but using another > method to find branches), and it checks for useless whiteouts (hoping I'm > not misunderstanding the thing). While it's working, it has only been > tested on 2 RW branches, the whiteout part has a beginning (I didn't check > all possibilities) of support for non-RW but permissions are not RW/RO > aware.
There is a script called auchk. (from README in aufs-util.git) ---------------------------------------------------------------------- o /usr/bin/auchk Similar to generic fsck. Checks whether a branch is healthy or not from aufs's point of view. ---------------------------------------------------------------------- (from aufs manual) ---------------------------------------------------------------------- If a sudden accident such like a power failure happens during aufs is performing, and regular fsck for branch filesystems is completed after the disaster, you need to extra fsck for aufs writable branches. It is necessary to check whether the whiteout remains incorrectly or not, eg. the real filename and the whiteout for it under the same parent directory. If such whiteout remains, aufs cannot handle the file correctly. To check the consistency from the aufs' point of view, you can use a simple shell script called /sbin/auchk. Its purpose is a fsck tool for aufs, and it checks the illegal whiteout, the remained pseudo\-links and the remained aufs\-temp files. If they are found, the utility reports you and asks whether to delete or not. It is recommended to execute /sbin/auchk for every writable branch filesystem before mounting aufs if the system experienced crash. ---------------------------------------------------------------------- Its purpose is very similar to yours, but what to check is different. I don't think your check_consistancy() is meaningful because users can change the file's mode, uid or gid anytime (and anywhere). To remove the whiteout-ed entries on the lower branch, there is a script called aubrsync in the same git tree. Also you may try aumvdown. > [1]: 2 RW branches on 3.2 kernel (OMV actually), 1 root cron script running > a sed -i command => leaves me 1 sed temporary file + it's whiteout each > time .. I suppose something's wrong but I can't figure what (or maybe it > is/was an aufs issue ?), or I just don't get everything. It looks more interesting to me. Would you post the details following the README file? ---------------------------------------------------------------------- When you have any problems or strange behaviour in aufs, please let me know with: - /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 - mailto: aufs-users at lists.sourceforge.net ---------------------------------------------------------------------- J. R. Okajima ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
