/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
