Messages in this thread | | | Date | Fri, 27 Sep 2013 13:50:13 -0700 | From | Zach Brown <> | Subject | Re: [RFC] extending splice for copy offloading |
| |
> > >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
| |