On Wed, Sep 22, 2010 at 12:16:42AM -0700, Nicholas A. Bellinger wrote: > On Mon, 2010-09-20 at 15:06 -0700, Joel Becker wrote: > > [Sorry on the delay, I was out of town] > > > > Many, thanks for your followup on this item, my comments are below. No problem. I'm sorry I was so busy that we couldn't iron this out a few months ago. I'm glad we're getting somewhere. > > On Fri, Sep 10, 2010 at 12:52:03PM -0700, Nicholas A. Bellinger wrote: > > > On Fri, 2010-09-10 at 12:44 -0700, Joel Becker wrote: > > Actually leaving the sub_child/group2/dst_0/dst_link in the example here > would be acceptable for the TCM MappedLUN case, because really we never > expect this case to this unless someone is poking at configfs directly, > and our userspace code will never do this intentionally. Right. If someone pokes around and makes it stop working, that's their fault. What we (configfs and TCM) must guarantee is that user poking doesn't cause a crash or put things in an unrecoverable state. "Remove all TCM mappins" is a valid recovery state, though "Recreate the symlink and it works again" is a better one. > > I'm saying that $object should count how many people are > > pointing to it, so that when you remove src_link, ACL is *not* freed. > > It will only be freed when both src_link and dst_link are removed. This > > way you do not crash. Perhaps I'm not understanding the ACL object. > > Perhaps I'm missing the mechanism entirely. But I don't see why the ACL > > object must necessarily be freed when one symlink is removed but not the > > other. > > > > No, I think your points here make perfect sense. I will look into a > patch that leaves the TCM fabric MappedLUNs symlinks in place when the > underlying TPG fabric LUN symlink is removed without breaking anything, > but still does the necessary accounting to ensure that shutdown with > active I/Os still works as expected. I will plan to drop the > ->check_link() patch from the forthcoming RFC v2 series. This sounds like a good plan for initial inclusion. > In the end I think his is the best approach for .37, eg: no configfs > change required. I am still open to the discussion for resolving this > within fs/configfs proper, but at this point I don't have a strong > preference and will follow your direction here. I think we can revisit this as necessary. Joel -- Life's Little Instruction Book #313 "Never underestimate the power of love." Joel Becker Consulting Software Developer Oracle E-mail: joel.becker@xxxxxxxxxx Phone: (650) 506-8127 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
