From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: "Lukáš Czerner" <lczerner@redhat.com>,
"Tomas Racek" <tracek@redhat.com>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: Automatic setting of {INODE,BLOCK}_UNINIT flags
Date: Thu, 25 Oct 2012 20:54:09 +0800 [thread overview]
Message-ID: <20121025125408.GA17378@gmail.com> (raw)
In-Reply-To: <CAGBYx2YbtPmCc5=OEKZoLHDj90oboUfBXBXm+BMVF-XMS8z0kg@mail.gmail.com>
On Thu, Oct 25, 2012 at 07:39:06PM +0800, Yongqiang Yang wrote:
> >
> > So my question is, why do you think this might not make sense in no
> > journal mode ? Maybe I am missing something.
> Yep, advantage is obvious, in no journal mode, if we delete a file
> which is the last inode in a block group, and the uninit flag of inode
> bitmap is flused to disk and directory referring the inode is not
> flushed, I don't know how fsck handles the situation currently. If
> fsck handles the situation, everything is ok. I meant maybe we should
> check fsck too.
Hi Yongqiang,
It seems that it couldn't happen whether it is in no journal mode or
journal mode. When a file is deleted, the dir entry will be updated
firstly, and then the block will be freed. So the block is freed after
the dir entry is updated. So when the last inode is freed, the dir
entry must be flushed to the disk. Am I missing something?
Regards,
Zheng
next prev parent reply other threads:[~2012-10-25 12:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 7:25 [PATCH] ext4: Automatic setting of {INODE,BLOCK}_UNINIT flags Tomas Racek
2012-10-25 7:44 ` Yongqiang Yang
2012-10-25 9:44 ` Lukáš Czerner
2012-10-25 11:39 ` Yongqiang Yang
2012-10-25 12:54 ` Zheng Liu [this message]
2012-10-25 13:59 ` Lukáš Czerner
2012-10-25 14:37 ` Andreas Dilger
2012-11-08 17:48 ` Theodore Ts'o
2012-12-20 9:48 ` Tomas Racek
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=20121025125408.GA17378@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tracek@redhat.com \
--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 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).