[LU-8834] Don't hide new functionality behind ioctls. Created: 15/Nov/16 Updated: 10/Sep/20 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.10.0 |
| Fix Version/s: | Upstream |
| Type: | Bug | Priority: | Minor |
| Reporter: | James A Simmons | Assignee: | Oleg Drokin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
The patch for LL_IOC_FUTIMES_3 was rejected upstream due to the functionality being done with a ioctl. Greg has requested that we don't make up new syscalls by making an ioctl. Please, make a new syscall if that's what you really need! This also impacts the ladvise work. |
| Comments |
| Comment by Doug Oucharek (Inactive) [ 15/Nov/16 ] |
|
Does this include utilities like Dynamic LNet Config (DLC)? |
| Comment by James A Simmons [ 15/Nov/16 ] |
|
Hmmm. This came up with the lustre versions of futimes and fadvise. He didn't complain before about DLC when it landed. I don't think he hates ioctls in general. just when using it for cases for functionality like already existing cases such as futimes. |
| Comment by Andreas Dilger [ 15/Nov/16 ] |
|
We could have the discussion with upstream about ladvise to link it into fadvise, but it is hard to say if this is a good fit or not, or if that is too Lustre specific. The main issue is that ladvise is for passing hints to the Lustre servers. As for futimes3, I agree that this may be of common interest. There may be some pushback because this allows setting the ctime() on a file, which other APIs do not. However, I believe XFS has support for similar functionality for their HSM integration. The other alternative would be to handle this internally on the MDS to set the OST timestamps during layout swap so that there isn't any need to set this from userspace. |
| Comment by John Hammond [ 10/Sep/20 ] |
|
> Please, make a new syscall if that's what you really need! This attitude is fine if you live in upstream developer La La Land. But we need to deliver functionality to support features in 3-6 months and not 10 years from now when all of our customers have upgraded to whatever kernel eventually gets that new syscall. Which is assuming it actually lands and doesn't get shot down by some other upstream gatekeeper. How long did statx() take? |