Re: [lustre-discuss] storing Lustre jobid in file xattrs: seeking feedback

2023-05-12 Thread Jeff Johnson 
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  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

Re: [lustre-discuss] storing Lustre jobid in file xattrs: seeking feedback

2023-05-12 Thread Andreas Dilger via lustre-discuss 
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 
mailto: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

[lustre-discuss] storing Lustre jobid in file xattrs: seeking feedback

2023-05-04 Thread Bertschinger, Thomas Andrew Hjorth via lustre-discuss 
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