[systemd-devel] more verbose debug info than systemd.log_level=debug?

[Michael Chapman]

On Mon, 10 Apr 2017, Mantas Mikulėnas wrote:
> On Mon, Apr 10, 2017 at 9:14 AM, Michael Chapman <mike at very.puzzling.org>
> wrote:
>
>> On Mon, 10 Apr 2017, Chris Murphy wrote:
>>
>>> On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering
>>> <lennart at poettering.net> wrote:
>>>
>>> That said, are you sure FIFREEZE is really what we want there? it
>>>> appears to also pause any further writes to disk (until FITHAW is
>>>> called).
>>>>
>>>
>>> So, I am still puzzled why the file system people think that "sync()"
>>>> isn't supposed to actually sync things to disk...
>>>>
>>>
>>> https://www.spinics.net/lists/linux-xfs/msg05113.html
>>>
>>
>> Ah good, Dave actually suggests using a freeze there. A freeze without a
>> corresponding thaw should be OK if it's definitely after all processes have
>> been killed, since we're just about to reboot anyway. (Obviously we'd want
>> to avoid the whole lot when running in a container or when doing kexec.)
>>
>
> Or, I think, when pivoting back to the shutdown-initramfs. (Though then you
> also need the shutdown-initramfs to run `fsfreeze`, I guess?)

No, I don't think it should be done then. If a filesystem is still in use, 
then doing a freeze there would likely make any processes still using it 
unkillable. And doing a freeze followed by a thaw doesn't gain us 
much, we'd still need to do another freeze at the end of 
shutdown-initramfs.

So I think we should only freeze any still-mounted filesystems *right* 
before the reboot(2) call. That's the only time it's guaranteed to be safe 
-- if there's still miraculously some other process hanging around, it's 
about to disappear anyway.

On the topic of XFS filesystem freezing, I just found this slide deck:

   http://oss.sgi.com/projects/xfs/training/xfs_slides_09_internals.pdf

Page 39 is of particular interest:

"""
sync(2)

* XFS implements an optimization to sync(2) of metadata:
   - XFS will only force the log out, such that any dirty
     metadata that is incore is written to the log only,
     the metadata itself is not necessarily written
   - This is safe, since all change is ondisk
   - File data is guaranteed too (even barriers)

* Log and metadata are written to disk for
   - freeze/thaw
   - remount ro
   - unmount

Applications like grub have been bitten in the past, but fixed nowadays
"""

I'm not sure what it's referring to with GRUB there, but at least this 
confirms what the filesystem developers' intentions are with the sync(2) 
call.