On Mon, May 13, 2019 at 5:57 PM David Sterba <dste...@suse.cz> wrote: > > On Mon, May 13, 2019 at 05:18:37PM +0100, Filipe Manana wrote: > > I would leave it as it is unless users start to complain. Yes, the > > test does this on purpose. > > Adding such code/state seems weird to me, instead I would change the > > rate limit state so that the messages would repeat much less > > frequently. > > The difference to the state tracking is that the warning would be > printed repeatedly, which I find unnecessary and based on past user > feedback, there will be somebody asking about that. > > The rate limiting can also skip a message that can be for a different > subvolume, so this makes it harder to diagnose problems. > > Current state is not satisfactory at least for me because it hurts > testing, the test runs for about 2 hours now, besides the log bloat. The
You mean the test case for fstests (btrfs/187) takes 2 hours for you? For me it takes under 8 minutes for an unpatched btrfs, while a patched btrfs takes somewhere between 1 minute and 3 minutes. This is on VMs, with a debug kernel, average/cheap host hardware, etc. > number of messages that slipped through ratelimiting is now over 11k, > which is roughly 150k messages printed overall.
