linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Linux Kernel Maling List <linux-kernel@vger.kernel.org>,
	Linux FS Maling List <linux-fsdevel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH v1 0/3] do not use s_dirt in FAT FS
Date: Thu, 12 Apr 2012 17:12:57 -0700	[thread overview]
Message-ID: <20120412171257.a0fc35b4.akpm@linux-foundation.org> (raw)
In-Reply-To: <1334144707-9729-1-git-send-email-dedekind1@gmail.com>

On Wed, 11 Apr 2012 14:45:04 +0300
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> The FAT file-system uses the VFS '->write_super()' method for writing out
> the FSINFO block, which contains useful but not critical information like
> the amount of free clusters.
> 
> This patch-set makes FAT FS use its own mechanisms for writing-out the FSINFO
> block and stop using the '->write_super()' VFS method. Namely, the FAT FS now
> submits a delayed work for writing out the FSINFO block once it becomes dirty.
> 
> The reason of this exercises is to get rid of the 'sync_supers()' kernel thread.
> This kernel thread wakes up every 5 (by default) and calls '->write_super()'
> for all mounted file-systems. And the bad thing is that this is done even if
> all the superblocks are clean. Moreover, some file-systems do not even need this
> end they do not register the '->write_super()' method at all (e.g., btrfs).
> 
> So 'sync_supers()' most often just generates useless wake-ups and wastes
> power. I am trying to make all file-systems independent of '->write_super()'
> and plan to remove 'sync_supers()' and '->write_super' completely once there
> are no more users.
> 
> Tested with xfstests.
> 
> Note: in the past I was trying to upstream patches which optimized 'sync_super()',
> but Al Viro wanted me to kill it completely instead, which I am trying to do now.

hm, I hadn't actually noticed the arrival of the sync_supers kernel
thread.

I don't think that the old scheme of calling sync_supers() via the
writeback (kudate) code was really appropriate.  ->write_super() is
mainly an fs-level function whose role is to push data from in-kernel
data structures down into the buffer_head layer (typically).  That
isn't a writeback function.

> ======
> Overall status:
> 
> 1. ext4: patches submitted, waiting for reply from Ted Ts'o:
>    https://lkml.org/lkml/2012/4/2/111
> 2. ext2: patches are in the ext2 tree maintained by Jan Kara:
>    git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
>    However, one patch is still not there:
>    http://www.spinics.net/lists/linux-ext4/msg31492.html
> 
> TODO: affs, exofs, hfs, hfsplus, jffs2, reiserfs, sysv, udf, ufs

That's a lot of work.

I don't really like the implementation.  It implies that we'll be
copying and pasting quite a lot of boilerplate delayed-work code into
many different filesystems.  Surely there is a way of hoisting the
common code up into the vfs library layer.

That implies that we retain ->write_super, probably in a modified form.
Modified to permit the VFS to determine whether the superblock needs
treatment, if ->s_dirt doesn't suffice.

The code as you've proposed it will cause more wakeups than needed - if
multiple filesystems are mounted and active, their timers will get out
of sync.  Which rather defeats the intent of the whole work!  This
problem should be addressable via some new centralised way of managing
things.

  parent reply	other threads:[~2012-04-13  0:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 11:45 [PATCH v1 0/3] do not use s_dirt in FAT FS Artem Bityutskiy
2012-04-11 11:45 ` [PATCH v1 1/3] fat: introduce fat_mark_fsinfo_dirty helper Artem Bityutskiy
2012-04-11 11:45 ` [PATCH v1 2/3] fat: mark fsinfo as dirty less often Artem Bityutskiy
2012-04-11 11:45 ` [PATCH v1 3/3] fat: self-manage own fsinfo block Artem Bityutskiy
2012-04-13  0:12 ` Andrew Morton [this message]
2012-04-13  6:38   ` [PATCH v1 0/3] do not use s_dirt in FAT FS Artem Bityutskiy
2012-04-13  7:26     ` Andrew Morton
2012-04-13  8:45       ` Artem Bityutskiy

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=20120412171257.a0fc35b4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=dedekind1@gmail.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).