All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Nathan Scott <nathans@sgi.com>
Cc: lkml@tlinx.org, helge.hafting@hist.no, linux-kernel@vger.kernel.org
Subject: Re: XFS: how to NOT null files on fsck?
Date: Thu, 5 Aug 2004 18:34:15 -0700	[thread overview]
Message-ID: <20040805183415.56230dce.akpm@osdl.org> (raw)
In-Reply-To: <20040806011059.GA774@frodo>

Nathan Scott <nathans@sgi.com> wrote:
>
>  On Thu, Aug 05, 2004 at 10:16:02AM +0200, Helge Hafting wrote:
>  > L A Walsh wrote:
>  > >Now I know it takes a while before data may end up on disk and that it
>  > >may not go out to disk in an ordered fashion, but 2-3 days?  
>  > 
>  > Seems strange to me, but the amount of delay is entirely up to the 
>  > filesystem.
> 
>  The flushing of dirty file data is actually performed by
>  kernel threads outside of the individual filesystems.
> 
>  I cannot explain a 2/3 day wait for data to get flushed,
>  something really strange going on for you there.

Well there was a writeback bug which could cause files to not get written
back ever.  Perhaps an unmount would cause writeback but nothing else would.

It was fixed by the below patch.  The situation will only arise with a
combination of a race and a data-synchronising writeback (O_SYNC, fsync,
etc).

It's unlikely that this is the cause of this report though.




From: Miklos Szeredi <miklos@szeredi.hu>

This patch fixes a hard-to-trigger condition, where the inode is on the
inode_in_use list while it's state is dirty.  In this state dirty pages are
not written back in sync() or from kupdate, only from direct page reclaim. 
And this causes a livelock in balance_dirty_pages after a while.

The actual sequence of events required to get into this state is:

thread   function                             inode state         inode list
----------------------------------------------------------------------------
1 __sync_single_inode (background)            I_DIRTY             sb->s_io
1 do_writepages ...                           I_LOCKED
2 __writeback_single_inode (sync) sleeps      I_LOCKED
1 __sync_single_inode (background) finish     0                   inode_in_use
2 __writeback_single_inode (sync) wakeup      0
2 __sync_single_inode (sync)                  0  
2 do_writepages ...                           I_LOCKED
3 __mark_inode_dirty                          I_LOCKED | I_DIRTY
2 __sync_single_inode (sync) finish           I_DIRTY             left on
                                                                  inode_in_use

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/fs/fs-writeback.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN fs/fs-writeback.c~fix-inode-state-corruption-268-rc1-bk1 fs/fs-writeback.c
--- 25/fs/fs-writeback.c~fix-inode-state-corruption-268-rc1-bk1	Fri Jul 16 15:06:57 2004
+++ 25-akpm/fs/fs-writeback.c	Fri Jul 16 15:06:57 2004
@@ -213,8 +213,9 @@ __sync_single_inode(struct inode *inode,
 		} else if (inode->i_state & I_DIRTY) {
 			/*
 			 * Someone redirtied the inode while were writing back
-			 * the pages: nothing to do.
+			 * the pages.
 			 */
+			list_move(&inode->i_list, &sb->s_dirty);
 		} else if (atomic_read(&inode->i_count)) {
 			/*
 			 * The inode is clean, inuse
_


      reply	other threads:[~2004-08-06  1:36 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-05  5:47 XFS: how to NOT null files on fsck? Norberto Bensa
2004-07-09 16:37 ` L A Walsh
2004-07-09 21:59   ` Chris Wedgwood
2004-07-10 18:33     ` L A Walsh
2004-07-10 18:43       ` Chris Wedgwood
2004-07-10 21:24         ` Bernd Eckenfels
2004-07-11 21:54           ` Helge Hafting
2004-07-12 17:56             ` H. Peter Anvin
2004-07-12 19:59               ` Chris Wedgwood
2004-07-12 20:32                 ` H. Peter Anvin
2004-07-12 22:29                 ` Bernd Eckenfels
2004-07-12 23:03       ` Bernd Eckenfels
2004-07-12 23:14         ` Chris Wedgwood
2004-07-10 18:43     ` Jan Knutar
2004-07-10 18:46       ` Chris Wedgwood
2004-07-10 18:55         ` Norberto Bensa
2004-07-10 19:19           ` Chris Wedgwood
2004-07-12 21:20             ` Chris Wedgwood
2004-07-12 22:40               ` L A Walsh
2004-07-12 22:53                 ` Chris Wedgwood
2004-07-13  1:44                   ` Bernd Eckenfels
2004-07-13  5:24                     ` Chris Wedgwood
     [not found]             ` <2hgxc-5x9-9@gated-at.bofh.it>
2004-07-13  7:25               ` Anton Ertl
2004-07-13  8:09                 ` Chris Wedgwood
2004-07-13  9:34                   ` Anton Ertl
2004-07-13  9:53                     ` Chris Wedgwood
2004-07-13 10:27                       ` Tim Connors
2004-07-13 10:38                         ` ismail dönmez
2004-07-13 11:16                           ` Nick Piggin
2004-07-13 12:52                             ` ismail dönmez
2004-07-13 10:58                         ` Chris Wedgwood
2004-07-13 13:33                       ` Anton Ertl
2004-07-13 20:32                         ` Chris Wedgwood
2004-07-13 22:42                           ` Bernd Eckenfels
2004-07-14 18:49                           ` Anton Ertl
2004-07-14 19:00                             ` Chris Wedgwood
2004-07-13 22:24                 ` Helge Hafting
2004-07-13 22:39                   ` Chris Wedgwood
2004-07-13 23:23                   ` Bernd Eckenfels
2004-07-14 18:53                   ` Anton Ertl
2004-07-10 19:33           ` Andreas Schwab
2004-07-10 19:40             ` Chris Wedgwood
2004-07-10 19:46             ` Norberto Bensa
2004-07-10 20:03               ` Chris Wedgwood
2004-07-11  1:21           ` Gopikrishnan Sidhardhan
2004-07-29  1:30   ` Nathan Scott
2004-08-03 18:31     ` L A Walsh
2004-08-04  0:48       ` Andi Kleen
2004-08-04  6:37         ` L A Walsh
2004-08-05  8:16       ` Helge Hafting
2004-08-06  1:10         ` Nathan Scott
2004-08-06  1:34           ` Andrew Morton [this message]

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=20040805183415.56230dce.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=helge.hafting@hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@tlinx.org \
    --cc=nathans@sgi.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.