Right, looks to me like the MDS never looks at them again unless they get a lookup from a client which references those pools in the layout. (IIRC this is really just there in case you are re-exporting to nfs. We were perhaps over-concerned about that in the early days, but we also didn’t expect any issues to be caused by having the backtrace objects. We were mostly right…)
On Tue, Jun 3, 2025 at 5:48 PM Hector Martin <mar...@marcan.st> wrote: > > > On 2025/06/04 0:49, Gregory Farnum wrote: > > On Mon, Jun 2, 2025 at 5:45 PM Hector Martin <mar...@marcan.st> wrote: > >> > >> On 2025/06/03 1:33, Gregory Farnum wrote: > >>> On Mon, Jun 2, 2025 at 6:12 AM Hector Martin <mar...@marcan.st> wrote: > >>>> I guess this is so existing clients can find the real pool if they > have > >>>> the old pool cached or something? > >>> > >>> Yes, that's why. We don't have any tools to help clean it up as it > >>> "shouldn't" have an impact and is a necessary part of the protocol in > >>> a lot of cases, though if you know you don't have clients touching > >>> files while they're attached to the old pool you can probably just > >>> remove them. > >>> -Greg > >> > >> Wouldn't the mds re-create them when the backtrace info is updated for > >> any reason (or worse, complain that they're missing as an > inconsistency)? > > > > I had to go check on this behavior :) but no, we store backtrace > > objects in the default pool and any extra pools just to forward to the > > correct pool. The pool the data actually gets written to is the only > > one the MDS will maintain in the future. > > And I'm guessing it won't assert or do anything bad on file deletion if > one of the backtrace objects is missing and it tries to delete it, > right? If so it should be safe ;) > > Thanks for checking! > > - Hector > > _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
