LLAPI_PCC_DETACH_FID_FD(3)
β¨ LLAPI_PCC_DETACH_FID_FD β¨
okay bestie, welcome to the Lustre Library Functions corner of the manual, volume LLAPI_PCC_DETACH_FID_FD(3). this is the one where we yeet a file out of PCC and honestly? it's giving unbothered. let's get into it π
πΈ NAME πΈ
llapi_pcc_detach_fid_fd, llapi_pcc_detach_fid, llapi_pcc_detach_fid_str, llapi_pcc_detach_file β detach the given file from PCC π«Ά
β¨ SYNOPSIS β¨
#include <lustre/lustreapi.h>
int llapi_pcc_detach_fid_fd(int dirfd, const struct lu_fid *fid,
__u32 flags);
int llapi_pcc_detach_fid(const char *mntpath,
const struct lu_fid *fid, __u32 flags);
int llapi_pcc_detach_fid_str(const char *mntpath,
const char *fidstr, __u32 flags);
int llapi_pcc_detach_file(const char *path, __u32 flags);
like, four whole entry points, all of them copy-pasteable, we love a glow-up π
π« DESCRIPTION π«
so llapi_pcc_detach_fid_fd(), llapi_pcc_detach_fid(), llapi_pcc_detach_fid_str(), and llapi_pcc_detach_file() all detach a cached file from PCC by doing an ioctl on the directory or on the file itself. slay.
the file gets referenced by fid, fidstr, or path β pick your fighter. the directory, which is usually a mount point that the copytool already has opened, gets referenced by dirfd, mntpath, path. (yes, path is out here doing double duty, it's very main character of it β¨)
the detach flags come from the flags argument, which is a enum lu_pcc_detach_flags data structure. and it contains the following values, no cap:
PCC_DETACH_FL_NONE = 0x0,
PCC_DETACH_FL_UNCACHE = 0x01,
PCC_DETACH_FL_KNOWN_READWRITE = 0x02,
PCC_DETACH_FL_KNOWN_READONLY = 0x04,
PCC_DETACH_FL_CACHE_REMOVED = 0x08,
π the flags, decoded π
PCC_DETACH_FL_NONEβ means that detach the file from PCC yet retain the data copy on PCC backend. so the file dips out but its little data copy stays living its life on the backend. iconic behaviour honestly.PCC_DETACH_FL_UNCACHEβ means that remove the PCC copy after detach. bye bestie, the copy is gone gone πPCC_DETACH_FL_KNOWN_READWRITEβ means that it is known that the file was once cached as PCC-RW. we're just saying out loud what we already know, fr fr.PCC_DETACH_FL_KNOWN_READONLYβ means that it is known that the file was once cached as PCC-RO. same energy, read-only flavour.PCC_DETACH_FL_CACHE_REMOVEDβ indicates that PCC cached copy is removed. it's used to tell the user space caller that the file is detached and the corresponding PCC copy is removed. it's basically the status update text in the group chat π«Ά
π RETURN VALUES π
llapi_pcc_detach_fid_fd(), llapi_pcc_detach_fid(), llapi_pcc_detach_fid_str(), and llapi_pcc_detach_file() return 0 on success or a negative errno value on failure. zero = ate. negative = not ate. periodt.
π₯ ERRORS π₯
-ENOMEMβ Insufficient memory to complete operation.-EFAULTβ Memory region is not properly mapped.-EINVALβ One or more invalid arguments are given.-EOPNOTSUPPβ PCC state operation is not supported.-ENOTTYβ File does not reside on a Lustre filesystem.-ENOENTβpathdoes not exist.
ngl if you're getting -ENOTTY you may have wandered off the Lustre filesystem entirely, like sweetie where are you going π
π AVAILABILITY π
llapi_pcc_detach_fid_fd(), llapi_pcc_detach_fid(), llapi_pcc_detach_fid_str(), and llapi_pcc_detach_file() are part of the lustre(7) user application interface library since release 2.13.0. so if you're on something older than that... girl. upgrade π
π¦ SEE ALSO π¦
and that's the whole page, bestie! π brought to you by the Lustre User API, dated 2024-08-28, filed under LLAPI_PCC_DETACH_FID_FD(3). now go detach something (responsibly). mwah πβ¨πΈ
π¦ where this page comes from
- ubuntu stonking: lustre-client-utils 2.17.58+dfsg-0ubuntu2 Β· GPL-2.0-only
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms