Problem with btrfs fs in 4.1.25 - getting EBUSY on file create - kernel.org bug 173001

Problem with btrfs fs in 4.1.25 - getting EBUSY on file create - kernel.org bug 173001

[Dave Olson]

The full details are in
https://bugzilla.kernel.org/show_bug.cgi?id=173001

Basicly, logrotate has rotated a file to a new name, tries to open a new
file with the original name, and gets EBUSY.  The file is not created.

Later on the file can be created with no problems.

I've turned on most of the BTRFS config options, and there are no BTRFS
messages related to the failure.

The file is on the root filesystem.


Dave Olson
olson@cumulusnetworks.com

Re: Problem with btrfs fs in 4.1.25 (also 4.8.0) - getting EBUSY on file create - kernel.org bug 173001

[Dave Olson]

Dave Olson <olson@cumulusnetworks.com> wrote:

> The full details are in
> https://bugzilla.kernel.org/show_bug.cgi?id=173001
> 
> Basicly, logrotate has rotated a file to a new name, tries to open a new
> file with the original name, and gets EBUSY.  The file is not created.
> 
> Later on the file can be created with no problems.
> 
> I've turned on most of the BTRFS config options, and there are no BTRFS
> messages related to the failure.
> 
> The file is on the root filesystem.

This problem is also reproducible on a 4.8 kernel.org kernel with no
modifications, built today from the 4.8 tag.

It happened on the 77th powercycle, after about 3 hours.

Dave Olson
olson@cumulusnetworks.com

Re: Problem with btrfs_create() getting EBUSY; cause is stale highest_objectid at mount - kernel.org bug 173001

[Dave Olson]

Dave Olson <olson@cumulusnetworks.com> wrote:

> Dave Olson <olson@cumulusnetworks.com> wrote:
> 
> > The full details are in
> > https://bugzilla.kernel.org/show_bug.cgi?id=173001
> > 
> > Basicly, logrotate has rotated a file to a new name, tries to open a new
> > file with the original name, and gets EBUSY.  The file is not created.

The cause is that the highest_objectid field in the btrfs_root structure
is set incorrectly (an old stale value) at filesystem mount in some
cases.   See the writeup in the bug for more details.

I'm guessing that some of the journal information is not flushed to disk
after btrfs_create(), even when the filesystem is mounted with
flushoncommit, so if a powercycle is done within a few seconds of the
file being created, there is a good chance that this problem will occur
on a subsequent reboot.

btrfs check (up through 4.7.3) does not seem to detect this stale
condition.

Dave Olson
olson@cumulusnetworks.com