Re: Problem with file system

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-11-06 13:45, Chris Murphy wrote:
> On Mon, Nov 6, 2017 at 6:29 AM, Austin S. Hemmelgarn
> <ahferroin7@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.
> 
Yes, but some still work, and they are invariably very new devices by 
most people's definitions.
>>> 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.
Yes.  However, from a simplicity of implementation perspective, it makes 
more sense to keep some number of old trees instead of keeping old trees 
for some amount of time.  That would remove the need to track timing 
info in the filesystem, provide sufficient protection, and probably be a 
bit easier to explain in the documentation.  Such logic could also be 
applied to regular block devices that don't support discard to provide a 
better guarantee that you won't overwrite old trees that might be useful 
for recovery.