<br><br><div class="gmail_quote">On Thu, Jan 20, 2011 at 3:17 PM, Aram Hăvărneanu <span dir="ltr"><<a href="mailto:aram.h@mgk.ro">aram.h@mgk.ro</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Case-insensitivity matching is required to avoid application confusion<br>
on the client side.  Applications expect either a case-sensitive<br>
namespace or a case-insensitive one (most Windows Application expect a<br>
case-insensitive namespace).  Applications are confused when case<br>
sensitivity is an arbitrary matter.<br>
<br>
ACLs are required for the same reason as case-sensitivity and also for<br>
administrative purposes. With CIFS it is common and expected that ACLs<br>
are set from the client side. Either they are set by the applications<br>
themselves, or administrators set them with Windows tools.  We make a<br>
promise that ACLs either exist or do now, and to keep this promise we<br>
need to have consistent behavior in all backing file systems.</blockquote><div><br></div><div>So the answer is that it does not break programmatic correctness (i.e. operations don't fail at the protocol level), but users and applications will be confused.  This should be explicitly stated in the spec.</div>
<div><br></div><div>So why is it OK that a parent filesystem supports system attributes but a child filesystem does not?  From the assertions above (correctness, confusion, expectations), it would seem that having one file that could have the archive bit set but a subdirectory with one that couldn't would be a bad thing.</div>
<div><br></div><div>It still seems to me that this should be configurable.  There are many users who would prefer to access to their data in a degraded form than no access at all.</div><div><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
At traversal time.</blockquote><div> </div></div><div>Please update the spec to indicate this.</div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> The proposal seems to overly simplify the SMB model (the relationship is not<br>
> actually 1:1),<br>
<br>
</div>I don't think the proposal simplifies the SMB model, this memo<br>
proposes changing what happens at traversal time.  There are other<br>
ways of creating SMB shares besides the sharesmb property<br>
(sharemgr(1M), MMC, etc) and those would continue to work as they do<br>
now. </blockquote><div><br></div><div>Right.  The spec made the incorrect statement that filesystems and shares have a 1:1 relationship, which was the source of much of my confusion.  It would be good to explain this in more detail before diving into sharesmb semantics.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> and I'm not sure I understand the fixation on 'sharesmb' as<br>
> the primary mechanism for communicating these semantics.<br>
<br>
</div>sharesmb creates a share, it was never a mechanism for controlling<br>
access (although many people interpreted sharesmb=off that way).<br>
While sharesmb=on behavior was explicitly documented, sharesmb=off<br>
behavior was never explained.  This proposal doesn't try to make<br>
sharesmb the primary mechanism for communicating CIFS semantics, on<br>
the contrary, it tries to document what sharesmb=off does and doesn't<br>
do.  The proposal is that sharesmb=off doesn't do anything and that<br>
it's possible to have (parts of) a filesystem exported via CIFS by<br>
other means.<br></blockquote><div><br></div><div>OK, that makes sense to me.  Perhaps it was some of the follow-on thread that confused the issue for me.  Based on that discussion and my own comments, it seems there is an opportunity to have a sharemgr(1M) option (which may or may not be exported over sharesmb) of something like traverse=<on|off|restricted>, with "restricted" being the default.</div>
<div><br></div><div>I definitely wouldn't change the ZFS-level inheritance semantics of sharesmb, as that could break existing deployments, and makes the assumption that child filesystems are necessarily mounted beneath the parent filesystem (an especially broken concept when the parent serves as a container and is not explicitly mounted).  One possibility would be to have something like "sharesmb=root", which has the semantics that a share is only instantiated if the property is set locally.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Correct, this memo is concerned only with the issue of traversing</div>
mounts, and while doing this touches the issue of what sharesmb<br>
actually means.  It's not concerned with alternative sharing methods.<br>
Those work as before.<br></blockquote><div><br></div><div>Please make this more explicit in the spec.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> What happens if I connect<br>
> over MMC and create a share beneath a sub-filesystem?  Will the SMB server<br>
> be smart enough to traverse all sub-mounts and load any sub-directory shares<br>
> such that they can be exported properly to administrative clients?<br>
<br>
</div>I am not sure what you mean by properly in this context, but yes, they<br>
are exported.<br></blockquote><div><br></div><div>What I mean is this:</div><div><br></div><div>1. Create an SMB share "PARENT" at /export/parent</div><div>2. Create a child filesystem at /export/parent/child</div>
<div>3. Create an SMB share "CHILD" at /export/parent/child/subdir</div><div><br></div><div>Now, when I connect to "PARENT" over MMC, am I able to create and manage shares within the child filesystem (i.e. the "CHILD" share)?  I'm not an MMC expert so I don't know how this is presented to the user, but if we're maintaining the view that this is a single filesystem, it seems like we necessarily have to be able to create and manage shares within sub-filesystems.  Can you elaborate on how this works today and what the user experience will be in the above scenario after your change?</div>
<div> </div><div>Given the number of comments, I'd like to see an updated spec incorporating feedback thus far and extend the timer another week.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"></div></blockquote></div><div>Thanks,</div><div><br></div><div>- Eric</div><div><br></div>-- <br><div>Eric Schrock, Delphix</div><br>