Re: [rfc] fsync_range?

[Jamie Lokier <jamie@shareable.org>]

jim owens wrote:
> Jamie Lokier wrote:
> >
> >Does O_DIRECT on btrfs still allocate new data blocks?
> >That's not very direct :-)
> >
> >I'm thinking if O_DIRECT is set, considering what's likely to request
> >it, it may be reasonable for it to mean "overwrite in place" too
> >(except for files which are actually COW-shared with others of course).
> 
> O_DIRECT for databases is to bypass the OS file data cache.
> 
> Those (oracle) who have long experience with it on unix
> know that the physical storage location can change on
> a filesystem.
> 
> I do not think we want to make a special case,
> it should be up to the db admin to choose cow/nocow
> because if they want SNAPSHOTS they need cow.

SNAPSHOTS is what "except for files which are actually COW-shared with
others of course" refers to.  An option to "choose" to corrupt
snapshots would be very silly.

Writing in place or new-place on a *non-shared* (i.e. non-snapshotted)
file is the choice which is useful.  It's a filesystem implementation
detail, not a semantic difference.  I'm suggesting writing in place
may do no harm and be more like the expected behaviour with programs
that use O_DIRECT, which are usually databases.

How about a btrfs mount option?
in_place_write=never/always/direct_only.  (Default direct_only).

-- Jamie