Steffen Dettmer:
> I assume the "most-likely" cause for us could be that some log
> message appearing systematically and frequently (without having
> automatic supression) resulting in multiple log files typically 5
> MB each, but of course there are measures against and the file
> system should never run full.
Unfortunately I am not sure what most-likely is.
Aufs is used by LiveCD/DVD/USB or something, and by servers. And I don't
know they are similar use-cases.
Anyway as long as you have rapidly growing multiple log files, I am
afraid that aufs as topmost writable tmpfs is not a good idea. As you
wrote, such log files will eat all disk space up in the end.
For such case, bind-mount /var/log may be better approach.
For example,
mount -t tmpfs none /rw
mount -t ext4 /dev/disk/by-uuid/... /ro
mount -t aufs -o br=/rw:/ro none /
mount -o bind /ro/var/log /var/log
> Yes, someone cannot safely remountrw/remountro/remountrw an ext4
:::
> bit problematic when it comes to be the root file system :)
Whao, it is a surprise for me...
> mmm... ok... What alternatives could be considered?
At first, we need to make sure which file is so large. XINO or log
files?
If it is the log files, then I'd suggest you to put them on your flash
by bind-mount. (Additionally you are "sync"ing files.)
If it is the aufs XINO files,
- at first, try truncating them by aufs re-mount options.
- if it doesn't work well, check these.
+ the size and the number of consumed blocks of XINO.
+ the used inode numbers in /rw.
if those inode numbers are distributed very widely and equally, then
truncating XINO files may not work well since this "truncating" is
very similar to "cp --sparse=always". It means if the XINO file
doesn't contain any "file-hole", then nothing will be truncated.
By the way, I am going to try refining the XINO truncation logic in a
few weeks.
> Do the debug files tell something helpful:
>
> xi0: 1, 48x4096 61440
> xi1: 1, 216x4096 122340
> xib: 8x4096 4096
> xigen: 16x4096 8192
>
> what is causing the issue?
The total number of blocks and bytes are
48 + 216 + 8 + 16 = 288 blocks
288 x 4096 = about 1.2 MB
Absolutely I don't think your XINO file is large. But it depends upon
the size of your /rw. How large is your /rw?
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
