DMFILEMAPD(8)

📦
version 2.03.29_1.02.203 · 3 versions
, in opensuse-leap 16.0

💖 DMFILEMAPD(8) 💖

okay so this is the dmfilemapd page, bestie — the device-mapper filemap monitoring daemon, and yes she is iconic for it 👑

✨ SYNOPSIS ✨

dmfilemapd file_descriptor group_id abs_path inode|path [foreground
[verbose]]

🌸 DESCRIPTION 🌸

Okay so listen: the dmfilemapd daemon is out here monitoring groups of dmstats(8) regions that correspond to the extents of a file, and she's literally adding and removing regions so everything reflects the changing state of the file on-disk. It's giving diligent. It's giving on top of it. 💅

Usually the daemon gets launched automatically by the dmstats create command, but bestie, you can run it manually — either to create a new daemon where one didn't previously exist, or to change the options that were previously used, by killing the existing daemon and starting a new one. Lowkey love that for us. ✨

🎀 OPTIONS 🎀

  • file_descriptor — Specify the file descriptor number for the file to be monitored, okay? The file descriptor must reference a regular file, open for reading, in a local file system that supports the FIEMAP ioctl, and that returns data describing the physical location of extents. Fr fr, those are the rules. And heads up: the process that executes dmfilemapd is responsible for opening the file descriptor that is handed to the daemon. No passing off the responsibility, bestie. 🫶
  • group_id — The dmstats group identifier of the group that dmfilemapd should update. The group must exist and it should correspond to a set of regions created by a previous filemap operation. Like, don't just make up a group ID, okay? It has to actually be there. 💀
  • abs_path — The absolute path to the file being monitored, at the time that it was opened. The use of abs_path by the daemon differs, depending on the filemap following mode in use; see MODES and the mode option for more information. Iykyk. 👀
  • inode|path — The filemap monitoring mode the daemon. Use either inode (DM_FILEMAP_FOLLOW_INODE), or path (DM_FILEMAP_FOLLOW_PATH), to enable follow-inode or follow-path mode respectively. Pick your fighter, bestie. 🌈
  • [foreground] — If set to 1, disable forking and allow the daemon to run in the foreground. She stays right there with you. 🎀
  • [verbose] — Control daemon logging. If set to zero, the daemon will close all stdio streams and run silently. If verbose is a number between 1 and 3, stdio will be retained and the daemon will log messages to stdout and stderr that match the specified verbosity level. So like, 1-3 is chatty, 0 is stealth mode. 🤫

🦋 MODES 🦋

The file map monitoring daemon can monitor files in two distinct ways: the mode affects the behaviour of the daemon when a file under monitoring is renamed or unlinked, and the conditions which cause the daemon to terminate. Bestie, this is important, don't skip it. ✨

In both modes, the daemon will always shut down when the group being monitored is deleted. Periodt. 💅

💜 Follow inode

The daemon follows the inode of the file, as it was at the time the daemon started. The file descriptor referencing the file is kept open at all times, and the daemon will exit when it detects that the file has been unlinked and it is the last holder of a reference to the file.

This mode is useful if the file is expected to be renamed, or moved within the file system, while it is being monitored. Like, she'll follow that inode anywhere. Obsessed. 🧚

💖 Follow path

The daemon follows the path that was given on the daemon command line. The file descriptor referencing the file is re-opened on each iteration of the daemon, and the daemon will exit if no file exists at this location (a tolerance is allowed so that a brief delay between removal and replacement is permitted).

This mode is useful if the file is updated by unlinking the original and placing a new file at the same path. Swap the file out, she'll find the new one. Slay. 🔥

😭 LIMITATIONS 😭

Okay so ngl, there are some caveats and I need you to hear them. The daemon attempts to maintain good synchronization between the file extents and the regions contained in the group, however, since the daemon can only react to new allocations once they have been written, there are inevitably some IO events that cannot be counted when a file is growing, particularly if the file is being extended by a single thread writing beyond EOF (for example, the dd program). So like, some events just get away. It's not her fault. 💀

There is a further loss of events in that there is currently no way to atomically resize a dmstats region and preserve its current counter values. This affects files when they grow by extending the final extent, rather than allocating a new extent: any events that had accumulated in the region between any prior operation and the resize are lost. RIP to those events, fr fr. 😭

File mapping is currently most effective in cases where the majority of IO does not trigger extent allocation. Future updates may address these limitations when kernel support is available. So like, watch this space, bestie. 👀

🍓 EXAMPLES 🍓

Normally the daemon is started automatically by the dmstats create or update_filemap commands but it can be run manually for debugging or testing purposes. Cute. Let's go. 💅

Start the daemon in the background, in follow-path mode:

# dmfilemapd 3 0 /srv/images/vm.img path 0 0 3< /srv/images/vm.img

Start the daemon in follow-inode mode, disable forking and enable verbose logging:

# dmfilemapd 3 0 /var/tmp/data inode 1 3 3< /var/tmp/data
Starting dmfilemapd with fd=3, group_id=0 mode=inode, path=/var/tmp/data
dm version   [ opencount flush ]   [16384] (*1)
dm info   (253:0) [ opencount flush ]   [16384] (*1)
dm message   (253:0) [ opencount flush ]  @stats_list dmstats [16384] (*1)
Read alias 'data' from aux_data
Found group_id 0: alias="data"
dm_stats_walk_init: initialized flags to 4000000000000
starting stats walk with   GROUP
exiting _filemap_monitor_get_events() with deleted=0, check=0
Waiting for check interval

Look at her go. Main character energy, honestly. 👑

🌟 AUTHORS 🌟

Bryn M. Reeves <bmr@redhat.com> — thank you for your service, king. 🫡

🌈 SEE ALSO 🌈

This page is from Linux, dated Dec 17 2016 — and that's the whole vibe, bestie. Stay mapped, stay monitored, and don't forget to check your extents. xoxo 💖✨🎀🦋🌸💅🫶😭🔥👑🌈⭐💀🙈🍓🧚💜
📦 where this page comes from