bothers to remove them. I guess it should...
OK, lots of InoIdx block have gone now with their DATA blocks.
+ So, remaining blocks are pinned to their phase with lots of Credits,
+ have not pincnt, mostly have physaddr==0.
+ It is just the stray refcnt that keeps them there..
+ inums are 40, 56, 62-73, 275-278, 280
+ 40 is f22
+ 56 is first adir
+ 63-69 are directories 2/3/4/5/6/7/8/9
+ 70-73 are looooong symlinks
+ 275 is cfile
+ 276 is dfile - same as cfile but truncated.
+ Then some nbfile-X that were big enough.
+
+ So: what do they have in common:
+ Several only use the in-inode data block, but
+ probably not all
+
+ Can it be that it is refcounted on the Leaf list, and so
+ cannot get off?? Yes, I think so!
+ We only unpin things that have a zero refcount.
+
+ So: what to do?
+ checkpoint takes it off the list, then flips the phase and puts it
+ on the other list with refile. During that time it has a refcount
+ it doesn't lose the pinning.
+ Do we want to:
+ 1/ Not have it on the list despite being pinned.
+ 2/ Drop the PIN despite the refcnt.
+ 3/ have refile do the phase_flip so it has a chance to
+ notice the refcount has hit zero.
+
+ 2 isn't really an option. We need PIN to persist whenver we have
+ a reference. We could possibly use PinPending for index blocks too,
+ but that would require a lot of thinking.
+ 1 requires another criterea for being on the list. I suspect that would
+ get messy fast.
+ 3 we used to do I think... But refile is in a big lock, and we
+ cannot really do a phase_flip under that.. and phase flip calls
+ refile anyway so we would get recursion.
+ So:4 - get lafs_phase_flip to notice and de-pin rather than flip.
+
+ FIXME use kzalloc where appropriate.
+
+ FIXME Maybe test refcnt-!listempty in refile and de-pin if that is zero.
+
+