All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Ding Dinghua <dingdinghua85@gmail.com>
Cc: Yongqiang Yang <xiaoqiangnk@gmail.com>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: Is this a bug?
Date: Sun, 3 Apr 2011 08:44:34 -0700	[thread overview]
Message-ID: <BANLkTimNwWxCr7Q1tRkQjxA=tQxvCNrw6g@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimpp7YeAWh-Eq8vKVAXAv=qKQgWew@mail.gmail.com>

On Sun, Apr 3, 2011 at 7:51 AM, Yongqiang Yang <xiaoqiangnk@gmail.com> wrote:
> On Sun, Apr 3, 2011 at 5:24 PM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
>> 2011/4/3 Amir Goldstein <amir73il@gmail.com>:
>>> On Sat, Apr 2, 2011 at 1:05 AM, Ding Dinghua <dingdinghua85@gmail.com> wrote:
>>>> When truncate files and free blocks, the following codes make me puzzled:
>>>>
>>>> void ext4_free_blocks(handle_t *handle, struct inode *inode,
>>>>                      struct buffer_head *bh, ext4_fsblk_t block,
>>>>                      unsigned long count, int flags)
>>>> {
>>>>        if (flags & EXT4_FREE_BLOCKS_FORGET) {
>>>>                struct buffer_head *tbh = bh;
>>>>                int i;
>>>>
>>>>                BUG_ON(bh && (count > 1));
>>>>
>>>>                for (i = 0; i < count; i++) {
>>>>                        if (!bh)
>>>>                                tbh = sb_find_get_block(inode->i_sb,
>>>>                                                        block + i);
>>>>                        if (unlikely(!tbh))
>>>>                                continue;
>>>>                        ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
>>>>                                    inode, tbh, block + i);
>>>>                }
>>>>        }
>>>> }
>>>>
>>>> I notice that ext4_forget mainly do two things:
>>>>    a)  call jbd2_journa_forget to forget the modification of some buffer head
>>>>    b)  or deal with the revoke issue
>>>> however, if we are freeing data blocks && ext4_forget get into branch a),
>>>
>>> Simple. we don't pass the FORGET flag when freeing data blocks,
>>> only when freeing metadata blocks, which may have been journalled
>>> already.
>>> I am not sure about the journal=data case through.
>> Thanks for reply. The reason for me to dip into this issue is journal=data mode.
> I think data processing in journal=data mode is similar to metadata
> processing in joutnal=ordered mode.

not exactly. Ding is right to be puzzled, because journal=data
journals inode page cache buffers and not block device buffers, like
metadata.
However, I think what happens is that prior to ext4_clear_blocks, which
invokes ext4_free_blocks with the FORGET flag, ext4_invalidatepage
will have been called already and forget about data buffers which were modified
in the current running transaction.
ext4_free_blocks will then handle revoke of data blocks which were modified in
previous transaction. for example, in orphan cleanup, ext4_free_blocks will be
will be called from ext4_truncate, but there will be no pages to invalidate.

this is my guess. I haven't studied this case thoroughly.

>>>
>>>> tbh is not the buffer_head which journal took care of in ext4_write_begin,
>>>> so i'm puzzled with this.
>>>>
>>>> Could anyone explain it to me? Thanks.
>>>>
>>>> --
>>>> Ding Dinghua
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>>
>> --
>> Ding Dinghua
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Best Wishes
> Yongqiang Yang
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-04-03 15:44 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-02  8:05 Is this a bug? Ding Dinghua
2011-04-02 16:32 ` Amir Goldstein
2011-04-03  9:24   ` Ding Dinghua
2011-04-03 14:51     ` Yongqiang Yang
2011-04-03 15:44       ` Amir Goldstein [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-06-21  3:08 Peter Teoh
2013-02-19  9:32 David Wade
2013-02-19  9:42 ` Andreas Ericsson
2013-02-19  9:47 ` Erik Faye-Lund
2013-02-19 11:02   ` Duy Nguyen
2013-02-22 19:29     ` Phil Hord
2013-02-22 21:48       ` Junio C Hamano
2011-06-21 21:57 Is this a Bug? Christian Deussen
2011-06-21 22:49 ` Greg Freemyer
2011-06-22  7:28   ` Wilson Felipe
2011-06-22 19:50     ` julie Sullivan
2011-06-22 21:21       ` julie Sullivan
2011-06-23 12:16         ` Christian D.
2011-06-23 13:03           ` Jonathan Neuschäfer
2011-06-23 18:49 ` Jonathan Neuschäfer
2011-03-24  0:46 is this a bug? Jay
2011-03-25 15:18 ` Steven Rostedt
2005-08-20  0:14 is this a bug ? Ashwin Chaugule
2005-08-19 13:19 ` Thomas Gleixner
2005-08-20  1:36   ` Ashwin Chaugule
2005-08-19 18:25     ` Thomas Gleixner
2005-08-19 19:31       ` ashwinc
2002-07-15 13:57 Is this a bug? Tisserand Patrice
2002-07-15 14:08 ` Takashi Iwai
2001-08-07 11:51 is " Thodoris Pitikaris
2001-08-07 13:51 ` Andrzej Krzysztofowicz
2001-08-08  2:19 ` Dr. Kelsey Hudson
2001-08-08  3:15   ` J Sloan
2001-08-08  3:45     ` Dr. Kelsey Hudson
2001-08-08 10:53       ` David Weinehall
2001-08-08 11:05   ` Alan Cox
2001-08-08 12:59   ` Ron Flory
2001-08-08 16:51 ` jury gerold
2001-08-10  9:12   ` Eric W. Biederman
2001-08-10 12:22     ` jury gerold
2001-08-10 16:22       ` Eric W. Biederman

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='BANLkTimNwWxCr7Q1tRkQjxA=tQxvCNrw6g@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=dingdinghua85@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=xiaoqiangnk@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.