From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ted Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: sb_dirt question
Date: Thu, 15 Mar 2012 17:00:40 +0200 [thread overview]
Message-ID: <1331823640.3730.40.camel@sauron.fi.intel.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
Hi Ted,
could you please commend on this commit of yours a bit:
commit a0375156ca1041574b5d47cc7e32f10b891151b0
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri Jun 11 23:14:04 2010 -0400
ext4: Clean up s_dirt handling
We don't need to set s_dirt in most of the ext4 code when journaling
is enabled. In ext3/4 some of the summary statistics for # of free
inodes, blocks, and directories are calculated from the per-block
group statistics when the file system is mounted or unmounted. As a
result the superblock doesn't have to be updated, either via the
journal or by setting s_dirt. There are a few exceptions, most
notably when resizing the file system, where the superblock needs to
be modified --- and in that case it should be done as a journalled
operation if possible, and s_dirt set only in no-journal mode.
This patch will optimize out some unneeded disk writes when using ext4
with a journal.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Let's take this hunk (I preserved more context than usual)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 5313ae4..bd411c1 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -110,33 +110,33 @@ static int ext4_file_open(struct inode * inode, struct file * filp)
if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED) &&
!(sb->s_flags & MS_RDONLY))) {
sbi->s_mount_flags |= EXT4_MF_MNTDIR_SAMPLED;
/*
* Sample where the filesystem has been mounted and
* store it in the superblock for sysadmin convenience
* when trying to sort through large numbers of block
* devices or filesystem images.
*/
memset(buf, 0, sizeof(buf));
path.mnt = mnt;
path.dentry = mnt->mnt_root;
cp = d_path(&path, buf, sizeof(buf));
if (!IS_ERR(cp)) {
memcpy(sbi->s_es->s_last_mounted, cp,
sizeof(sbi->s_es->s_last_mounted));
- sb->s_dirt = 1;
+ ext4_mark_super_dirty(sb);
}
As I read this, it means that if do have journal, do not bother writing
out the updated superblock at all. When the superblock will be written
out then?
Thanks!
P.S. The reason I look at this is because I am trying to make sure ext4
does not use s_dirty and does not rely on VFS calling 'write_super()' at
all. I guess I will try to use a delayed work instead and move 's_dirt'
to sbi. The reason of this exercise is that I want to eliminate
'sync_supers()' completely, because it wakes up every 5 seconds no
matter what, and Al wanted me to push SB handling down to file-systems.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
reply other threads:[~2012-03-15 14:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1331823640.3730.40.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=linux-ext4@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).