lkml.org 
[lkml]   [2015]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] vfs: add a O_NOMTIME flag
On Tue, 12 May 2015, Dave Chinner wrote:
> > > Neither of these examples cases are under the control of the
> > > application that calls open(O_NOMTIME).
> >
> > Wouldn't a mount option (e.g., allow_nomtime) address this concern? Only
> > nodes provisioned explicitly to run these systems would be enable this
> > option.
>
> Back to my Joe Speedracer comments.....
>
> I'm not sure what the right answer is - mount options are simply too
> easy to add without understanding the full implications of them.
> e.g. we didn't merge FALLOC_FL_NO_HIDE_STALE simply because it was
> too dangerous for unsuspecting users. This isn't at that same level
> or concern, but it's still a landmine we want to avoid users from
> arming without realising it...
>
> > > >> I'm happy for it to be an ioctl interface - even an XFS specific
> > > >> interface if you want to go that route, Sage - and it probably
> > > >> should emit a warning to syslog first time it is used so there is
> > > >> trace for bug triage purposes. i.e. we know the app is not using
> > > >> mtime updates, so bug reports that are the result of mtime
> > > >> mishandling don't result in large amounts of wasted developer time
> > > >> trying to understand them...
> > > >
> > > > A warning on using the interface (or when mounting with user_nomtime)
> > > > sounds reasonable.
> > > >
> > > > I'd rather not make this XFS specific as other local filesystmes (ext4,
> > > > f2fs, possibly btrfs) would similarly benefit. (And if we want to target
> > > > XFS specifically the existing XFS open-by-handle ioctl is sufficient as it
> > > > already does O_NOMTIME unconditionally.)
> > >
> > > Lack of a namespace, doesn't imply that you don't want to manage the
> > > data. The whole point of using object storage instead of plain old
> > > block storage is to be able to provide whatever metadata you still
> > > need in order to manage the object.
> >
> > Yeah, agreed--this is presumably why open_by_handle(2) (which is what we'd
> > like to use) doesn't assume O_NOMTIME.
>
> Right - the XFS ioctls were designed specifically for applications
> that interacted directly with the structure of XFS filesystems and
> so needed invisible IO (e.g. online defragmenter). IOWs, they are
> not interfaces intended for general usage. They are also only
> available to root, so a typical user application won't be making use
> of them, either.

I understand that's what they're intended for, but I'm having a hard time
parsing out the difference between what they *do* and what O_NOMTIME + -o
allow_nomtime does. The open-by-handle ioctls have nothing to do with the
online XFS format--they simply allow you to open a file via an opaque
handle (albeit a differently formatted one than the generic
open_by_handle_at(2)). They also force you into an O_NOMTIME-equivalent
mode.

AFAICS the only difference that I see is that

1) the ioctl is XFS specific. (As open_by_handle_at(2) demonstrates, this
needn't be the case.)

2) the NOMTIME mode is only available via the open-by-handle interface,
not open(2).

3) it is an ioctl interface, and thus more obscure. (Well, there is a
libhandle library, but it doesn't seem to be widely used.)

Would you object less if

1) the O_NOMTIME flag were only available via open_by_handle_at(2)?

2) an equivalent ioctl were implemented for each file system of interest
that (say) called into open_by_handle_at(2) code, adding in the O_NOMTIME
flag?

3) O_NOMTIME required root (vs a mount option that requires root and
unpriviledged O_NOMTIME)?

Just trying to tease apart which part is problematic...

Thanks!
sage



\
 
 \ /
  Last update: 2015-05-13 01:21    [W:0.107 / U:0.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site