On Mon, May 13, 2019 at 09:10:03PM +0200, David Sterba wrote: > On Mon, May 13, 2019 at 06:05:54PM +0100, Filipe Manana wrote: > > On Mon, May 13, 2019 at 5:57 PM David Sterba <dsterba@xxxxxxx> 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? > > This is on a VM with file-backed devices, that I use for initial tests > of patches before they go to other branches. Update: it took about 6 minutes in another round, so the test does work in that setup.
