Problem with btrfs fs in 4.1.25 - getting EBUSY on file create - kernel.org bug 173001
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
[email protected]
Re: Problem with btrfs fs in 4.1.25 (also 4.8.0) - getting EBUSY on file create - kernel.org bug 173001
Quoted 6 lines · Dave Olson
The full details are in
https://bugzilla.kernel.org/show_bug.cgi?id=173001Basicly, 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.
Quoted 6 lines
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
[email protected]
Re: Problem with btrfs_create() getting EBUSY; cause is stale highest_objectid at mount - kernel.org bug 173001
Quoted 7 lines · Dave Olson
Quoted 5 lines · Dave Olson
The full details are in
https://bugzilla.kernel.org/show_bug.cgi?id=173001Basicly, 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
[email protected]