Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
Lustre 2.10.0
-
None
-
3
-
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.
Attachments
Issue Links
- is related to
-
LU-9680 Improve the user land to kernel space interface for lustre
-
- In Progress
-
Activity
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.
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.
Does this include utilities like Dynamic LNet Config (DLC)?
> 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?