resize_root / resize_ffs (with logging file system)

[Christof Meerwald <cmeerw%cmeerw.org@localhost>]

/etc/rc.d/resize_root doesn't attempt to resize a file system if it
has the "log" flag set in /etc/fstab, but I am wondering what the
reason is behind that check.

I think my immediate issue with this check is that it doesn't
necessarily mean that the filesystem actually already has logging
enabled (as the filesystem could have been prepared without logging
and the presence of "log" in fstab just means that logging will be
enabled the first time the filesystem is mounted read-write).

The other observation is that resize_ffs doesn't complain about
resizing a filesystem with logging enabled (and it even seems to
work). What is the problem with resizing those logging file systems?
Is it that the journal size would need to be adjusted, but resize_ffs
currently can't do that? Shouldn't it check for a journal and
warn/abort in that case?

Back to the resize_root script? Should that maybe instead of checking
the fstab flag look at the actual filesystem with dumpfs (to maybe
check for "wapbl version")?

Or to put it another way - once logging has been enabled, is it safe
to remove the "log" mount flag (remount the file system), resize the
file system, and then re-enable the "log" flag? Currently, the script
would allow that case.


BTW, my use case would be to create a filesystem image (without
logging), but already set "log" in fstab, so that on the first boot
the filesystem gets resized and then when it is mounted the first time
"read-write" on the machine, logging gets enabled with the resized
file system. To achieve this, I have patched the resize_root script to
check the "wapbl version" instead of the "log" flag from fstab. Does
that make sense?


Christof

-- 

https://cmeerw.org                             sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org