Just a thought, instead of embedding the jobname itself, perhaps just a least significant 7 character sha-1 hash of the jobname. Small chance of collision, easy to decode/cross reference to jobid when needed. Just a thought.
--Jeff On Fri, May 12, 2023 at 3:08 PM Andreas Dilger via lustre-discuss < lustre-discuss@lists.lustre.org> wrote: > Hi Thomas, > thanks for working on this functionality and raising this question. > > As you know, I'm inclined toward the user.job xattr, but I think it is > never a good idea to unilaterally make policy decisions in the kernel that > cannot be changed. > > As such, it probably makes sense to have a tunable parameter like " > mdt.*.job_xattr=user.job" and then this could be changed in the future if > there is some conflict (e.g. some site already uses the "user.job" xattr > for some other purpose). > > I don't think the job_xattr should allow totally arbitrary values (e.g. > overwriting trusted.lov or trusted.lma or security.* would be bad). One > option is to only allow a limited selection of valid xattr namespaces, and > possibly names: > > - NONE to turn this feature off > - user, or trusted or system (if admin wants to restrict the ability > of regular users to change this value?), with ".job" added > automatically > - user.* (or trusted.* or system.*) to also allow specifying the xattr > name > > If we allow the xattr name portion to be specified (which I'm not sure > about, but putting it out for completeness), it should have some reasonable > limits: > > - <= 7 characters long to avoid wasting valuable xattr space in the > inode > - should not conflict with other known xattrs, which is tricky if we > allow the name to be arbitrary. Possibly if in trusted (and system?) > it should only allow trusted.job to avoid future conflicts? > - maybe restrict it to contain "job" (or maybe "pbs", "slurm", ...) to > reduce the chance of namespace clashes in user or system? However, I'm > reluctant to restrict names in user since this *shouldn't* have any > fatal side effects (e.g. data corruption like in trusted or system), > and the admin is supposed to know what they are doing... > > > On May 4, 2023, at 15:53, Bertschinger, Thomas Andrew Hjorth via > lustre-discuss <lustre-discuss@lists.lustre.org> wrote: > > Hello Lustre Users, > > There has been interest in a proposed feature > https://jira.whamcloud.com/browse/LU-13031 to store the jobid with each > Lustre file at create time, in an extended attribute. An open question is > which xattr namespace is to use between "user", the Lustre-specific > namespace "lustre", "trusted", or even perhaps "system". > > The correct namespace likely depends on how this xattr will be used. For > example, will interoperability with other filesystems be important? > Different namespaces have their own limitations so the correct choice > depends on the use cases. > > I'm looking for feedback on applications for this feature. If you have > thoughts on how you could use this, please feel free to share them so that > we design it in a way that meets your needs. > > Thanks! > > Tom Bertschinger > LANL > _______________________________________________ > lustre-discuss mailing list > lustre-discuss@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > > > Cheers, Andreas > -- > Andreas Dilger > Lustre Principal Architect > Whamcloud > > > > > > > > _______________________________________________ > lustre-discuss mailing list > lustre-discuss@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org > -- ------------------------------ Jeff Johnson Co-Founder Aeon Computing jeff.john...@aeoncomputing.com www.aeoncomputing.com t: 858-412-3810 x1001 f: 858-412-3845 m: 619-204-9061 4170 Morena Boulevard, Suite C - San Diego, CA 92117 High-Performance Computing / Lustre Filesystems / Scale-out Storage
_______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
