On 07/19/2016 08:11 PM, Gabriel C wrote:
On 19.07.2016 13:05, Chris Mason wrote:
On Mon, Jul 11, 2016 at 11:28:01AM +0530, Chandan Rajendra wrote:
Hi Chris,
I am able to reproduce the issue with the 'short-write' program. But before
the call trace associated with btrfs_destroy_inode(), I see the following call
trace ...
------------[ cut here ]------------
WARNING: CPU: 2 PID: 2311 at
/home/chandan/repos/linux/fs/btrfs/extent-tree.c:4303
btrfs_free_reserved_data_space_noquota+0xe8/0x100
[ ... ]
Ok, the problem is in how we're dealing with the offset into the sector when
we fail. The dirty_sectors variable already has this accounted in it, so
this patch fixes it for me. I ran overnight, but I'll let it go for a few
days just to make sure:
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index fac9b839..5842423 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1629,13 +1629,11 @@ again:
* managed to copy.
*/
if (num_sectors > dirty_sectors) {
- /*
- * we round down because we don't want to count
- * any partial blocks actually sent through the
- * IO machines
- */
- release_bytes = round_down(release_bytes - copied,
- root->sectorsize);
+
+ /* release everything except the sectors we dirtied */
+ release_bytes -= dirty_sectors <<
+ root->fs_info->sb->s_blocksize_bits;
+
if (copied > 0) {
spin_lock(&BTRFS_I(inode)->lock);
BTRFS_I(inode)->outstanding_extents++;
Since I guess you are testing this on latest git code I started to test on
latest stable.
Any v4.7-rc or v4.6 stable where the patch applies ;)
Until now all seems file .. your test program is still running without to
trigger the bug.
Also thunderbird is running without to trigger the bug.
I let it run overnight and report back.
Great, thanks!
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
