On Mon, Mar 16, 2015 at 10:14:42AM +0000, Steven Hartland wrote: > > On 16/03/2015 09:21, Matthew D. Fuller wrote: > > On Mon, Mar 16, 2015 at 02:08:45AM +0100 I heard the voice of > > Pawel Jakub Dawidek, and lo! it spake thus: > >> Overall the patch looks good. The main concern I have is that we do > >> nothing if the underlying provider returns EOPNOTSUPP on BIO_DELETE, > >> we will just keep sending those requests. > > Well, they're all coming from the layer above us, and it'll get back > > the EOPNOTSUPP's, so if it keeps sending them anyway that seems more > > like its problem than ours. It seems like intercepting the response > > (that would mean making our own new request, getting the response, > > then making that response ourselves to the original?) wouldn't really > > save much of anything, and adds a lot of extra bug-havens... > > > See how ZFS details with this, it adds internal state to the device > which stores and bypasses the pass down after the first EOPNOTSUPP. > > This avoids the full stack round trip, which when volumes of deletes are > high could be noticeable.
By ZFS is at the top of the stack, GELI is just passing through the requests. I agree with Matt that ZFS is the one who should handle EOPNOTSUPP from the underlying provider, not GELI. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "[email protected]"
