Steffen Dettmer: > Wouldn't this just delay the problem a little bit (until some log > file consumes some more bytes)?
It depends upon how you use aufs. If the disk space pressure is caused by a few big files, then expanding /rw will not be effective (as you wrote). But if the pressure is caused by the XINO files (due to the large number of files), it will be helpful I guess. Because expanding tmpfs will make aufs easier to truncate the XINO files. Note that the size of a XINO file depends upon the maximum inode number and how many inodes are used on branch fs. > Should "ls" show /rw/.aufs.xino? I don't have such files (only > /rw/.wh..wh.aufs, /rw/.wh..wh.orph, /rw/.wh..wh.plnk, are they > related?). No. The XINO files are created and removed internally and you cannot see it. So aufs shows its size via debugfs. > It is a compact flash with (to me) unknown max number of write > cycles with ext4. The idea was to keep it read-only "all the > time", except for file updates (software configuration file > updates) for two reasons: first to be care about flash aging and > second to avoid that rw mounted ext4 causes file system failures > on power failure (which is the normal "shutdown") - interactive > questions at boot would render the embedded units useless of > course :) However, remounting rw, syncing (we use a simple > command like "rsync --delete /rw /ro", but I had to check) works > fine, but remountro often starts to moan about orphaned inodes in > ext4 and no more remoutrw are possible without reboot - which > seems to be a known problem. So currently we never remountro > after syncing. Not sure if this is good... Just out of curious, is it a known problem "of ext4"? In order to move files between aufs branches, I'd suggest you to try "aubrsync" utility in aufs-util.git. It handles all whiteoutes and pseudo-links well, but the tool is for the shutdown-time only. For a running system, a new utility "aumvdown" is recommended. But I am still working on it and not completed yet. Additionally aumvdown is for aufs3.9 and later... Anyway, back on topic :) > Would it be recommended to store XINO files on it's own tmpfs, for example? Does it mean - mount another tmpfs - put XINO files on that tmpfs and separating them from /rw? It is a good approach to identify the cause of your problem, but I am not sure whether it will be a good solution for you. > So I "simulated" a full disk by using: > > # while true; do dd if=/dev/zero of=large.log.$((n++)) bs=1M count=10 ; done > > but I assume it has an effect on XINO files whether there are a > few big or a lot of small files? The size of XINO file is depending the number of files basically. It means still we are not sure that the cause of the problem is XINO or not... J. R. Okajima ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
