Since you've decided to *pin* them, they'll stay pinned to whichever ranks they've been pinned to. The pinning strategy can be overridden for subdirs. But as long as you don't touch the pinning strategy for a subdir, the subdirs stay pinned to the rank that the closest parent dir has been pinned to. FYI - https://docs.ceph.com/en/pacific/cephfs/multimds/#manually-pinning-directory-trees-to-a-particular-rank On Sun, Oct 9, 2022 at 5:12 PM Frank Schilder <frans@xxxxxx> wrote: > Hi Milind, > > super, thanks! That's good enough for me. > > Just one stupid question. Will the ephemerally pinned sub-trees will > always stay entirely on the same MDS rank? I really want to avoid sub-tree > exports for folders under /home etc, meaning also avoiding sub-tree exports > for a path like /home/x/y/z. > > Thanks and good Sunday. > ================= > Frank Schilder > AIT Risø Campus > Bygning 109, rum S14 > > ________________________________________ > From: Milind Changire <mchangir@xxxxxxxxxx> > Sent: 09 October 2022 09:24:20 > To: Frank Schilder > Cc: ceph-users@xxxxxxx > Subject: Re: How to check which directory has ephemeral > pinning set? > > On Sat, Oct 8, 2022 at 7:27 PM Frank Schilder <frans@xxxxxx<mailto: > frans@xxxxxx>> wrote: > Hi all, > > I believe I enabled ephemeral pinning on a home dir, but I can't figure > out how to check that its working. Here is my attempt: > > Set the flag: > # setfattr -n ceph.dir.pin.distributed -v 1 /mnt/admin/cephfs/hpc/home > > Try to read it: > # getfattr -n ceph.dir.pin.distributed /mnt/admin/cephfs/hpc/home > /mnt/admin/cephfs/hpc/home: ceph.dir.pin.distributed: No such attribute > > This is a known issue for pre-pacific releases. > There's a fix in pacific v16.2.8 and later which returns values of > ceph.dir.pin* virtual xattrs correctly. > > To try to see if the distributed pin flag has indeed been set, you could > try getting an inode dump with: > $ ceph tell mds.0 dump inode <inode_number> > > and check for the field export_ephemeral_distributed_pin to get the value > of that field for that inode. > > However, you might have to iterate through the mds ranks to get the inode > if the inode has been identified as *hot* and has been distributed to some > other mds. > e.g. > $ ceph tell mds.2 dump inode <inode-number> > > You can get the dir inode number with: > $ ls -lid /mnt/admin/cephfs/hpc/home > > Similarly, if you iterate through all the immediate subdirs of > /mnt/admin/cephfs/hpc/home and get inode dumps, you'll get to know which > mds is the auth mds for the inode when you actually get the inode dump from > the particular mds rank. The mds from which you get the inode dump is the > mds that the node has been distributed to for auth queries and responses. > > > > > Hmm. ??? > > Well, at least the first command might have done something, because this > fails: > # setfattr -n ceph.dir.pin.distrid -v 1 /mnt/admin/cephfs/hpc/groups > setfattr: /mnt/admin/cephfs/hpc/groups: Invalid argument > > What is the right way to confirm its working? > > Thanks and best regards, > ================= > Frank Schilder > AIT Risø Campus > Bygning 109, rum S14 > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx<mailto:ceph-users@xxxxxxx> > To unsubscribe send an email to ceph-users-leave@xxxxxxx<mailto: > ceph-users-leave@xxxxxxx> > > > > -- > Milind > > -- Milind _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |