linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Hunt <johunt@akamai.com>
To: "stable@vger.kernel.org" <stable@vger.kernel.org>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"tytso@mit.edu" <tytso@mit.edu>, "jack@suse.cz" <jack@suse.cz>
Subject: Re: [PATCH] ext4: fix warning in ext4_da_update_reserve_space()
Date: Wed, 21 Jan 2015 21:31:13 -0600	[thread overview]
Message-ID: <54C06F01.7090604@akamai.com> (raw)
In-Reply-To: <1420750108-11512-1-git-send-email-johunt@akamai.com>

On 01/08/2015 02:48 PM, Josh Hunt wrote:
>      Please add the patch below and referenced dependency (0e95c22) to stable
>      3.10.y. The original 7d73453 did not apply cleanly to my 3.10.y so I've
>      backported it here. Its dependency can be cherry-picked.
>
>      I've gotten approval to submit these to 3.10 stable from Jan and Ted, also
>      cc'd.
>      http://marc.info/?l=linux-ext4&m=142070334408249&w=2
>
>      Thanks
>      Josh
>
>      -----
>
>      commit 7d7345322d60edb0fa49a64a89b31360f01d09cb upstream
>
>      reaim workfile.dbase test easily triggers warning in
>      ext4_da_update_reserve_space():
>
>      EXT4-fs warning (device ram0): ext4_da_update_reserve_space:365:
>      ino 12, allocated 1 with only 0 reserved metadata blocks (releasing 1
>      blocks with reserved 9 data blocks)
>
>      The problem is that (one of) tests creates file and then randomly writes
>      to it with O_SYNC. That results in writing back pages of the file in
>      random order so we create extents for written blocks say 0, 2, 4, 6, 8
>      - this last allocation also allocates new block for extents. Then we
>      writeout block 1 so we have extents 0-2, 4, 6, 8 and we release
>      indirect extent block because extents fit in the inode again. Then we
>      writeout block 10 and we need to allocate indirect extent block again
>      which triggers the warning because we don't have the reservation
>      anymore.
>
>      Fix the problem by giving back freed metadata blocks resulting from
>      extent merging into inode's reservation pool.
>
>      Cc: <stable@vger.kernel.org> # 3.10.x: 0e95c22: quota: provide interface for readding allocated space into reserved space
>      Cc: <stable@vger.kernel.org> # 3.10.x
>      Signed-off-by: Jan Kara <jack@suse.cz>

I've just realized the patch dependency I referenced above, 0e95c22, is 
incorrect. It should have been 1c8924eb106. Sorry for any confusion.

Let me know if I you'd like me to respin the patch with the proper hash 
information.

Thanks
Josh

  reply	other threads:[~2015-01-22  3:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08 20:48 [PATCH] ext4: fix warning in ext4_da_update_reserve_space() Josh Hunt
2015-01-22  3:31 ` Josh Hunt [this message]
2015-01-28  0:12 ` Greg KH
2015-01-28  0:14   ` Josh Hunt
2015-02-03 22:53 ` Greg KH
2015-02-03 22:57   ` Josh Hunt
2015-02-03 23:13     ` Greg KH
2015-02-03 23:15       ` Josh Hunt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54C06F01.7090604@akamai.com \
    --to=johunt@akamai.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).