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. > > > 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. > > 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). >>
-- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 ---------------------------------------------------------------------
