LLAPI_PCC_DETACH_FID_FD(3)

πŸ“¦ version 2.17.58, in ubuntu stonking

✨ 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 β€” path does 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