linux-kernel - Re: [PATCH 0/3] dm raid/raid1: enable discard support when any devices support discard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9cb6a39a43178be29af2f47a92c2e84754b62b69.camel@bonedaddy.net>
Date:   Sun, 19 Apr 2020 22:48:16 +0800
From:   Paul Wise <pabs3@...edaddy.net>
To:     Mike Snitzer <snitzer@...hat.com>
Cc:     Alasdair Kergon <agk@...hat.com>, dm-devel@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] dm raid/raid1: enable discard support when any
 devices support discard

On Sun, 2020-04-19 at 09:19 -0400, Mike Snitzer wrote:

> You went overboard with implementation before checking to see if your
> work would be well received.  Your 2/3 patch header shows you're
> capable of analyzing past commits to explain the evolution of code,
> etc.  But yet you make no mention of this commit header which explicitly
> speaks to why what you're proposing is _not_ acceptable:
> 
> commit 8a74d29d541cd86569139c6f3f44b2d210458071
> Author: Mike Snitzer <snitzer@...hat.com>
> Date:   Tue Nov 14 15:40:52 2017 -0500
> 
>     dm: discard support requires all targets in a table support discards

I do remember seeing this commit while working on this, I guess I
ignored it in my attempts to get fstrim working on my rootfs, woops.

> I haven't looked closely at MD raid in this area but if you trully think
> underlying MD raid can cope with issuing discards to devices that don't
> support them (or that it avoids issuing them?) then please update
> dm-raid.c to conditionally set ti->discard_supported (if not all devices
> support discard).  That is how to inform DM core that the target knows
> better and it will manage discards issued to it.  It keeps the change
> local to dm-raid.c without the flag-day you're proposing.

On my system I have a HDD and an SSD, with /boot on MD RAID and / on
ext4 on DM RAID on 2 DM crypt volumes. In this setup fstrim works on
/boot but does not work on / and with my patches it works on / again.
In addition I don't see any messages in dmesg or other issues when
doing fstrim / with my patches.

I think I might have been worried that discards_supported has other
side effects but grepping the code now I see that was unfounded.
I'll switch the next version to just setting discards_supported.
I still think that my proposed overboard design is clearer though :)

You'll see from the following command that MD raid 0/1/10 arrays enable
discards when any device supports discards:

   git grep -wW discard_supported

It appears that the block layer ignores discard requests when the queue
for the block device indicates that discard is not supported on it:

   git grep -wW __blkdev_issue_discard

It seems to me that where possible DM/MD letting the block layer decide
to pass on or ignore discard requests is the right design. I'm possibly
incorrectly assuming that all block device drivers will correctly
advertise support for discard without false positive/negatives.

BTW, any idea where I should fix the `fstrim --fstab` issue? It is
expecting the queue/discard_granularity sysfs entry to be non-zero.
From my initial debugging attempts it seems raid_io_hints is at fault.

Thanks for your initial response and any further insight you can give.

-- 
bye,
pabs

https://bonedaddy.net/pabs3/

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)