On 07/13/09 07:13, Rick Matthews wrote: > Comments in-line. > > On 07/11/09 20:52, Alan.M.Wright wrote: >> Having a TCR against Samba in order to allow this (or any) fasttrack >> to be approved on the basis that the fasttrack is not the right solution >> but resolves a customer problem seems a bit strange to me. > TCR was probably an unfortunate use of the term. My intended meaning was > that for Solaris 10, the existing Solaris 10 interface be used (as > defined in this > fast track). For OpenSolaris, the requirement should be for Samba to use to > the new interface as defined by PSARC/2007/315.
That's fine by me. >> If we agree that adding a system attribute is the appropriate >> solution, we >> should pursue that now. The fact that SAMFS would require a change >> to support system attributes shouldn't really have a bearing on selecting >> the appropriate architectural solution, and if that's a concern >> perhaps we can talk about that offline. > Yes, we should pursue it now in OpenSolaris. I don't think it would be wise > to require the project team to implement (or coordinate implementation) of > system attributes, the required SAM-QFS change and the Samba change in > a Solaris 10 release. Okay. Alan >> Alan >> -- >> >> Rick Matthews wrote: >>> Darren, >>> >>> I agree with Alan's proposal that the existing system extended >>> attributes be expanded >>> to include "offline" or whatever the appropriate tag could be. This >>> would require a change >>> to SAM-QFS to support Solaris extended attributes in at least the >>> case of that flag (a SAM-QFS >>> project/case, I'd guess) and modifying the interfaces introduced in >>> PSARC/2007/315 to include >>> the newly defined flag. >>> This case appears to be asking to use existing interfaces of SAM-QFS >>> to cause the >>> Solaris provided samba to detect a condition that is causing the >>> described customer >>> problem, and mitigate it. The resultant FILE_ATTRIBUTE_OFFLINE within >>> the >>> SMB_QUERY_FILE_BASIC_INFO appears to be standard (at least in the SNIA >>> document). >>> I would think that advise to the PAC about modifying SAM-QFS to at >>> least support >>> an system extended attribute for offline, and for some unknown group >>> to add that to >>> the existing system extended attributes would be an appropriate >>> response. >>> In the mean time, I would think this case could be approved with a >>> TCR to modify >>> the version of Samba shipped by Sun when the architecturally >>> appropriate interfaces >>> (those using the existing infrastructure described in PSARC/2007/315) >>> exist in Sun >>> current and future HSM products. >>> I could help add this to the general opinion, or add it as a >>> minority opinion. >>> == >>> Rick >>> >>> On 07/ 9/09 04:33 AM, Darren J Moffat wrote: >>>> Alan.M.Wright wrote: >>>>> Providing this as a temporary solution to relieve a customer problem >>>>> is excellent. My disagreement is that it should be committed as a >>>>> long term solution for offline support when we already have a defined >>>>> system attribute mechanism that could be used to solve the problem >>>>> via libc. >>>> >>>> Given the above I'm derailing this case for the purpose of writing >>>> an opinion with Advice to fund the above mentioned project and to >>>> point out the issue of adding Solaris/Sun functionality to Samba >>>> with no planned match for the in kernel CIFS server. >>>> >>>> PSARC members please are you willing to vote based on the above our >>>> would you like to see draft opinion text first. I've marked the >>>> case as "waiting need vote" for now. >>>> >>>> Note that this is *derail* not *deny* (though depending on the vote >>>> it could be but I doubt it). >>> > >
