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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
