Hi! Thanks so much for your quick and so detailed response!!
> > What can we do to avoid this? > The basic and simple solution is to enlarge the size of the upper branch. Wouldn't this just delay the problem a little bit (until some log file consumes some more bytes)? 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?). > if you have a space on HDD 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... Anyway, back on topic :) Would it be recommended to store XINO files on it's own tmpfs, for example? > I'd suggest you to mount debugfs 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? Then I extracted the debug output - hopefully correctly - using debugfs: # mkdir /tmp/debug # mount -t debugfs /debug /tmp/debug root@mydev:/tmp/debug/aufs/si_6e43b585# tail -n 100 * ==> xi0 <== 1, 48x4096 61440 ==> xi1 <== 1, 216x4096 122340 ==> xib <== 8x4096 4096 ==> xigen <== 16x4096 8192 If this are sizes in bytes, they seem to be quite small. So truncating would not be effective, right? So better store it on it's own tmpfs? Could a similar thing happen to the ".wh..wh.*" files, too? Best regards, Steffen ------------------------------------------------------------------------------ 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
