| Message ID | 20200419073026.197967-1-pabs3@bonedaddy.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | dm raid/raid1: enable discard support when any devices support discard | expand |
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@redhat.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.
On 4/19/20 4:48 PM, Paul Wise wrote: > 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@redhat.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. Did you have discard allowed on both dm-crypt devices? dm-crypt (kernel) does not allow discards by default. Regards O. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, 2020-04-20 at 09:35 +0200, Ondrej Kozina wrote: > Did you have discard allowed on both dm-crypt devices? dm-crypt > (kernel) does not allow discards by default. I did not, I guess that explains why I got no errors.
On 4/20/20 12:13 PM, Paul Wise wrote: > On Mon, 2020-04-20 at 09:35 +0200, Ondrej Kozina wrote: > >> Did you have discard allowed on both dm-crypt devices? dm-crypt >> (kernel) does not allow discards by default. > > I did not, I guess that explains why I got no errors. > FYI if you use LUKS2 metadata format for encrypted drives, you can enable discards by default once and for all by following command: cryptsetup open /dev/sdx sdx_unlocked --allow-discards --persistent Any following unlock will enable discards automatically. Regards O. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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. ... > 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. So, now that I know that my approach to this was completely bogus, what *is* the correct way to safely enable mixed-discard support? It seems to me that the right way would be one of these options: * a sysfs toggle for the block layer * an lvchange based option for the dm layer I'm leaning towards the latter for my personal use-case but the former would make Linux much more flexible but would touch more code and have the potential for more damage.