Do block device changes propgate to mounts

YuvalAvra · 01-27-2020, 12:04 PM

I've been using debugfs to write/change block devices directly, and I'm seeing inconsistencies when it comes to existing mounts of that block device, the changes I make don't always appear in the mount.

When do changes to the block device propagate to existing mount points of that device?
If the mount is read-only - does that have any effect?

For example:

Code:

$ debugfs -w /dev/rootfs_device
 (debugfs) cd lib64
 (debugfs) write my_library.so library.so
 (debugfs) close -a
$ ls -al /lib64  # Changes don't always propagate to mount (maybe there's a correlation to file size?)

Thanks

rknichols · 01-27-2020, 12:37 PM

Any data blocks or filesystem metadata that the kernel is holding in its cache will continue to be used, and if any of that gets altered in the running system the dirty blocks will be written out to the disk, overwriting your changes. You can easily end up with the filesystem metadata in an inconsistent state (data blocks being used in an inode but marked free in the block map, that sort of thing), so it's a really bad idea to be writing to a mounted filesystem.

YuvalAvra · 01-28-2020, 03:32 AM

Quote:

Originally Posted by rknichols

Any data blocks or filesystem metadata that the kernel is holding in its cache will continue to be used, and if any of that gets altered in the running system the dirty blocks will be written out to the disk, overwriting your changes. You can easily end up with the filesystem metadata in an inconsistent state (data blocks being used in an inode but marked free in the block map, that sort of thing), so it's a really bad idea to be writing to a mounted filesystem.

Thanks! that makes sense.
Come to think about it, I'm not sure how any file I created was propagated to the mount, as the wouldn't appear in the dentry cache.
Perhaps the file was created in a directory that was yet to be touched by the running system?

rknichols · 01-28-2020, 08:44 AM

Quote:

Originally Posted by YuvalAvra

Perhaps the file was created in a directory that was yet to be touched by the running system?

Most likely. The block bitmap would still be a concern. If the kernel is using a cached version of the portion of the map that you've altered, that mismatch would create a situation that needs to be cleaned up by fsck, with a possibility of corrupted files.