That logging issue should be fixed in an upcoming commit: https://github.com/ceph/ceph/pull/19220/commits/fb7a4cf2aaf68dc5e16733d8daf2e1bf716f183a The export is aborted because the pin is checked before migration begins: https://github.com/ceph/ceph/blob/a903a769df69a47f838e5b9cb1d9eb843bca6e4b/src/mds/Migrator.cc#L812-L815 On Thu, Apr 5, 2018 at 6:29 AM, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: > Or maybe I'm just confused by the balancer logging. > > For example,I have a dir > /volumes/_nogroup/393f2dcc-6b09-44d7-8d20-0e84b072ed26 that is pinned > to mds.2. > > Via the 'get subtrees' command I see the exports/pins are correct on all mds's. > > The confusing part is that in mds.2's log I see things like: > > 2018-04-05 15:27:00.648233 7f6bb2db5700 0 mds.2.migrator nicely > exporting to mds.0 [dir 0x300012b92ee > /volumes/_nogroup/393f2dcc-6b09-44d7-8d20-0e84b072ed26/user/thibaut/Cell2OctopanOnlyNHITBF1SEY2EnergyHistDtChange/ > [2,head] auth v=38822 cv=38758/38758 state=1610612738|complete f(v0 > 11=10+1)/f(v0 m2018-04-03 13:30:46.987621 11=10+1) n(v3336 > rc2018-04-05 15:26:50.412158 b1058833426 2350=2341+9) hs=11+0,ss=0+0 > dirty=3 | child=1 dirty=1 waiter=0 authpin=0 0x56340a1e4a00] > > But that appears not to happen, because the get subtrees remain the > same afterwards. > > -- dan > > > > On Thu, Apr 5, 2018 at 3:05 PM, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: >> Hi Patrick, >> >> We are using pinning [1] on a few directories but after some network >> outages today (and MDS restarts) I noticed that subtrees below pins we >> set weeks ago were being split across MDSs. >> So are the pins meant to be persisted? >> >> I clearly see the "nice exports" happening at the moment of setfattr >> -n ceph.dir.pin, but we can't view that xattr so it isn't clear if the >> pins are persisted at all. >> >> Best Regards, >> >> Dan >> >> [1] https://ceph.com/community/new-luminous-cephfs-subtree-pinning/ -- Patrick Donnelly -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
