Re: [PATCH 2/2] Btrfs: sync log after logging new name

[Filipe Manana <fdmanana@kernel.org>]

On Tue, Aug 14, 2018 at 11:53 PM, David Sterba <dsterba@suse.cz> wrote:
> On Tue, Aug 14, 2018 at 12:04:05PM -0700, Omar Sandoval wrote:
>> On Mon, Jun 18, 2018 at 01:06:16PM +0200, David Sterba wrote:
>> > On Fri, Jun 15, 2018 at 05:19:07PM +0100, Filipe Manana wrote:
>> > > On Fri, Jun 15, 2018 at 4:54 PM, David Sterba <dsterba@suse.cz> wrote:
>> > > > On Mon, Jun 11, 2018 at 07:24:28PM +0100, fdmanana@kernel.org wrote:
>> > > >> From: Filipe Manana <fdmanana@suse.com>
>> > > >> Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes")
>> > > >> Reported-by: Vijay Chidambaram <vvijay03@gmail.com>
>> > > >> Signed-off-by: Filipe Manana <fdmanana@suse.com>
>> > > >
>> > > > There are some warnings and possible lock up caused by this patch, the
>> > > > 1/2 alone is ok but 1/2 + 2/2 leads to the following warnings. I checked
>> > > > twice, the patch base was the pull request ie. without any other 4.18
>> > > > stuff.
>> > >
>> > > Are you sure it's this patch?
>> > > On top of for-4.18 it didn't cause any problems here, plus the trace
>> > > below has nothing to do with renames, hard links or fsync at all -
>> > > everything seems stuck on waiting for IO from dev replace.
>> >
>> > It was a false alert, sorry. Strange that the warnings appeared only in
>> > the VM running both patches and not otherwise.
>> >
>> > Though the test did not directly use rename, the possible error scenario
>> > I had in mind was some leftover from locking, error handling or state
>> > that blocked umount of 011.
>>
>> Dave, are you sending this in for 4.19? I don't see it in your first
>> pull request.

In another thread, related to the first patch in the series iirc, I
specifically asked to not merge it.
That's because I run twice (in the long period of nearly 2 months now)
into a hang which could be caused
by this patch. The traces were weird and only contained inexact lines
that showed only the transaction kthread
waiting forever on transaction commit.

I recently found that I have hardware problems that were causing
issues with qemu (stalls, ocassional crashes)
so I'm hoping that's the cause but I still need to test it with long
stress tests on good hardware.

I don't mind getting it to linux-next in the meanwhile, but for 4.19 I
would prefer to not include yet.

>
> Will send it in 2nd pull for 4.19. The patch is 2 months old and I don't
> remember where it was lost on the way. I had some suspicions but turned
> out to be false. Thanks for the reminder.