PMEM_MAP_FILE(3)
π PMEM_IS_PMEM(3) π
okay bestie, welcome to the PMDK Programmer's Manual β¨ this one's all about pmem_is_pmem(), pmem_map_file() and pmem_unmap() β checking persistency, and making + deleting mappings. literally the glow-up your raw memory access needed π«Ά
πΈ NAME πΈ
pmem_is_pmem(), pmem_map_file(), pmem_unmap() β check persistency, create and delete mappings π
β¨ SYNOPSIS β¨
#include <libpmem.h>
int pmem_is_pmem(const void *addr, size_t len);
void *pmem_map_file(const char *path, size_t len, int flags, mode_t mode,
size_t *mapped_lenp, int *is_pmemp);
int pmem_unmap(void *addr, size_t len);
π¦ DESCRIPTION π¦
okay so most pmem-aware applications are gonna be living their best life with the higher level libraries, because those libraries mean the app doesn't have to call into libpmem directly at all. no cap. but if you're the kind of dev who wants to access raw memory mapped persistence directly (like, via mmap(2)) and you're ready to take on the responsibility for flushing stores to persistence yourself? then the functions in this section are the ones you'll be reaching for most. main character energy tbh π
The pmem_is_pmem() function detects if the entire range [addr, addr+len) consists of persistent memory. calling this function with a memory range that originates from a source different than pmem_map_file() is undefined β like, undefined undefined, don't do it π
Also, the implementation of pmem_is_pmem() requires a non-trivial amount of work to figure out if the given range is entirely persistent memory. so for that reason, it's way better to call pmem_is_pmem() once when a range of memory is first encountered, save the result, and then use that saved result to decide whether pmem_persist(3) or msync(2) is the right move for flushing changes to persistence. calling pmem_is_pmem() every single time you flush changes to persistence? it will not perform well. it's giving performance L π
The pmem_map_file() function creates a new read/write mapping for a file. If PMEM_FILE_CREATE is not specified in flags, then the entire existing file path is mapped, len must be zero, and mode is ignored. otherwise, path is opened or created as specified by flags and mode, and len must be non-zero. pmem_map_file() maps the file using mmap(2), but it also takes extra steps to make large page mappings more likely. slay π
On success, pmem_map_file() returns a pointer to the mapped area. If mapped_lenp is not NULL, the length of the mapping is stored into *mapped_lenp. If is_pmemp is not NULL, a flag indicating whether the mapped file is actual pmem, or if msync() must be used to flush writes for the mapped range, is stored into *is_pmemp. iykyk π
The flags argument is 0 or the bitwise OR of one or more of the following file creation flags:
PMEM_FILE_CREATEβ create the file namedpathif it does not exist.lenmust be non-zero and specifies the size of the file to be created. if the file already exists, it will be extended or truncated tolen. the new or existing file is then fully allocated to sizelenusingposix_fallocate(3).modespecifies the mode to use in case a new file is created (seecreat(2)). π
The remaining flags modify the behavior of pmem_map_file() when PMEM_FILE_CREATE is specified:
PMEM_FILE_EXCLβ if specified in conjunction withPMEM_FILE_CREATE, andpathalready exists, thenpmem_map_file()will fail withEEXIST. otherwise, it has the same meaning asO_EXCLonopen(2), which is generally undefined. π«£PMEM_FILE_SPARSEβ when specified in conjunction withPMEM_FILE_CREATE, create a sparse (holey) file usingftruncate(2)rather than allocating it usingposix_fallocate(3). otherwise ignored. π³οΈβ¨PMEM_FILE_TMPFILEβ create a mapping for an unnamed temporary file. must be specified withPMEM_FILE_CREATE.lenmust be non-zero,modeis ignored (the temporary file is always created with mode0600), andpathmust specify an existing directory name. if the underlying file system supportsO_TMPFILE, the unnamed temporary file is created in the filesystem containing the directorypath; ifPMEM_FILE_EXCLis also specified, the temporary file may not subsequently be linked into the filesystem (seeopen(2)). otherwise, the file is created inpathand immediately unlinked. π«
The path can point to a Device DAX. in this case only the PMEM_FILE_CREATE and PMEM_FILE_SPARSE flags are valid, but they are both ignored. for Device DAX mappings, len must be equal to either 0 or the exact size of the device. π
To delete mappings created with pmem_map_file(), use pmem_unmap().
The pmem_unmap() function deletes all the mappings for the specified address range, and causes further references to addresses within the range to generate invalid memory references. it will use the address specified by the parameter addr, where addr must be a previously mapped region. pmem_unmap() will delete the mappings using munmap(2).
π RETURN VALUE π
The pmem_is_pmem() function returns true only if the entire range [addr, addr+len) consists of persistent memory. a true return from pmem_is_pmem() means it is safe to use pmem_persist(3) and the related functions to make changes durable for that memory range. see also CAVEATS. β
On success, pmem_map_file() returns a pointer to the memory-mapped region and sets *mapped_lenp and *is_pmemp if they are not NULL. on error, it returns NULL, sets errno appropriately, and does not modify *mapped_lenp or *is_pmemp. π
On success, pmem_unmap() returns 0. on error, it returns -1 and sets errno appropriately.
π§ NOTES π§
pmem_is_pmem() returns true if the entire range was mapped directly from Device DAX (/dev/daxX.Y) without an intervening file system, or MAP_SYNC flag of mmap(2) is supported by the file system on Filesystem DAX. π
π CAVEATS π
The result ofpmem_is_pmem()query is only valid for the mappings created usingpmem_map_file(). for other memory regions, in particular those created by a direct call tommap(2),pmem_is_pmem()always returns false, even if the queried range is entirely persistent memory. π
Not all file systems supportposix_fallocate(3).pmem_map_file()will fail ifPMEM_FILE_CREATEis specified withoutPMEM_FILE_SPARSEand the underlying file system does not supportposix_fallocate(3). π€
π SEE ALSO π
creat(2), ftruncate(2), mmap(2), msync(2), munmap(2), open(2), pmem_persist(3), posix_fallocate(3), libpmem(7) and https://pmem.io π₯
and that's the whole page bestie!! this one's from the PMDK crew, dated 2025-07-24 β go forth and map responsibly, mwah π πβ¨
π¦ where this page comes from
- fedora 43: libpmem-devel 2.1.0-4.fc43 Β· BSD-3-Clause
- π the page's license: BSD-3-Clause
- Copyright 2017-2023, Intel Corporation
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms