On 10/07/2015 21:01, Pawel Jakub Dawidek wrote:
On Sun, Jun 28, 2015 at 08:38:41PM -0500, Matthew D. Fuller wrote:
Stuffed into bugzilla as
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198860>
[...]
After last round, everybody seems happy enough with this, so I've
filed it as
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198863>.
Does anybody have outstanding concerns on these? Or, if not, what
else do we need to move them along? They're working fine for me
here...
Ping... still working fine here, and I'm pretty sure I've addressed
every concern anybody's raised.
Matthew,
I'm sorry that it took me so long to get to your patch.
The good news is that I like the patch - it looks clean and complete.
The bad news is that I like it a bit too much:) I think I'd prefer that
BIO_DELETE is passed through by default and there is an option to turn
it off. This would mean changing -t option to -T for init and onetime
and renaming the G_ELI_FLAG_DELETE flag to G_ELI_FLAG_IGNORE_DELETE.
OR... just removing the ability to ignore BIO_DELETEs. The latter is
appealing especially if some days we will implement BIO_DELETEs as
overwrites. Then we should have an option to turn that on, which would
turn off TRIM/UNMAP.
Thinking about it some more, I believe that if someone doesn't want
TRIM/UNMAP to hit his SSDs it should be configurable on per-SSD basis
and not on every layer above SSD. So at the end I'd change my preference
to just passing BIO_DELETEs always.
This can already be achieved for devices attached via cam/scsi_da e.g.
kern.cam.da.1.delete_method="NONE"
What do you think?
_______________________________________________
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
