Re: [PATCH v1 0/9] do not use s_dirt in ext4

From: Artem Bityutskiy
Date: Tue Mar 27 2012 - 09:27:21 EST


On Thu, 2012-03-22 at 11:33 +0100, Jan Kara wrote:
> Then we have ext4_mark_super_dirty() call from 4 places - I forgot about
> these originally... I kind of miss their purpose. Originally they were used
> so that we write total number of free blocks and inodes in the superblock
> but when we do not maintain them in the journal mode I don't see a reason
> to periodically sync them in no-journal mode. Ted, what is the purpose of
> these calls?

I do not understand what's the fundamental difference between journal
and non-journal mode. Why when we do have the journal we do not mark the
super-block as dirty in many places (e.g., in 'ext4_file_open()' - if we
do have the journal, when do we make sure we save the mount point path
change?).

May be it has something to do with behaving like the ext2 driver when
mounting ext2-formatted media with the the ext4 driver?

Jan, since Ted did not answer, may be you can figure out the reasons
from this commit message, which actually introduced the
'ext4_mark_super_dirty()' function?


commit a0375156ca1041574b5d47cc7e32f10b891151b0
Author: Theodore Ts'o <tytso@xxxxxxx>
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@xxxxxxx>

--
Best Regards,
Artem Bityutskiy

Attachment: signature.asc
Description: This is a digitally signed message part