> > >Sure. So we'd have: > > > > > >- no flag default that forbids knowingly copying with shared references > > > so that it will be used by default by people who feel strongly about > > > their assumptions about independent write durability. > > > > > >- a flag that allows shared references for people who would otherwise > > > use the file system shared reference ioctls (ocfs2 reflink, btrfs > > > clone) but would like it to also do server-side read/write copies > > > over nfs without additional intervention. > > > > > >- a flag that requires shared references for callers who don't want > > > giant copies to take forever if they aren't instant. (The qemu guys > > > asked for this at Plumbers.) > > Why not implement only the last flag only as the first step? It seems > like the simplest one. So I think that would mean: > > - no worrying about cancelling, etc. > - apps should be told to pass the entire range at once (normally > the whole file). > - The NFS server probably shouldn't do the internal copy loop by > default. > > We can't prevent some storage system from implementing a high-latency > copy operation, but we can refuse to provide them any help (providing no > progress reports or easy way to cancel) and then they can deal with the > complaints from their users.
I can see where you're going with that, yeah. It'd make less sense as a splice extension, then, perhaps. It'd be more like a generic entry point for the existing ioctls. Maybe even just defining the semantics of a common ioctl. Hmm. > Also, I don't get the first option above at all. The argument is that > it's safer to have more copies? How much safety does another copy on > the same disk really give you? Do systems that do dedup provide > interfaces to turn it off per-file? Yeah, got me. It's certainly nonsense on a lot of FTL logging implementations (which are making their way into SMR drives in the future). > But I understand that Zach's tired of the woodshedding and I could live > with the above I guess.... No, it's fine. At least people are expressing some interest in the interface! That's a marked improvement over the state of things in the past. - z -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
