On Mon, Nov 6, 2017 at 6:29 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
> > With ATA devices (including SATA), except on newer SSD's, TRIM commands > can't be queued, SATA spec 3.1 includes queued trim. There are SATA spec 3.1 products on the market claiming to do queued trim. Some of them fuck up, and have been black listed in the kernel for queued trim. >> >> >> Anyway right now I consider discard mount option fundamentally broken >> on Btrfs for SSDs. I haven't tested this on LVM thinp, maybe it's >> broken there too. > > For LVM thinp, discard there deallocates the blocks, and unallocated regions > read back as zeroes, just like in a sparse file (in fact, if you just think > of LVM thinp as a sparse file with reflinking for snapshots, you get > remarkably close to how it's actually implemented from a semantic > perspective), so it is broken there. In fact, it's guaranteed broken on any > block device that has the discard_zeroes_data flag set, and theoretically > broken on many things that don't have that flag (although block devices that > don't have that flag are inherently broken from a security perspective > anyway, but that's orthogonal to this discussion). So this is really only solvable by having Btrfs delay, possibly substantially, the discarding of metadata blocks. Aside from physical device trim, there are benefits in thin provisioning for trim and some use cases will require file system discard, being unable to rely on periodic fstrim. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
