xfs
[Top] [All Lists]

Re: XFS problem on shutdown

To: Jason White <jasonjgw@xxxxxxxxxxxxxx>
Subject: Re: XFS problem on shutdown
From: Keith Owens <kaos@xxxxxxxxxxxxxxxxx>
Date: Wed, 19 Dec 2001 10:30:31 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Your message of "Wed, 19 Dec 2001 10:01:54 +1100." <15391.51938.657659.988167@gargle.gargle.HOWL>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Wed, 19 Dec 2001 10:01:54 +1100, 
Jason White <jasonjgw@xxxxxxxxxxxxxx> wrote:
>Thank you for the excellent advice. I have two more questions, then we
>can bring this thread to a close - I hope.
>
>1. Does Linux 2.4.14 with the XFS 1.0.2 patch applied contain an
>   unmount bug? If not, then we can presumably conclude that it was
>   the drive's write cache; and I will update to the latest Debian
>   sysvinit package.

Stock 2.4.14 does not have the bug, it was introduced in 2.4.15-pre8.
Unless Eric included the patch from 2.4.15-pre8 in the 1.0.2 release,
you do not have the problem.  AFAICR this patch introduced the bug, if
this change is not in your tree then you are OK.

Index: 15-pre7.1/fs/inode.c
--- 15-pre7.1/fs/inode.c Tue, 20 Nov 2001 15:39:10 +1100 kaos 
(linux-2.4/p/b/14_inode.c 1.7.1.2.1.5.1.1.1.4.1.8 644)
+++ 15-pre8.1/fs/inode.c Thu, 22 Nov 2001 11:15:28 +1100 kaos 
(linux-2.4/p/b/14_inode.c 1.7.1.2.1.5.1.1.1.4.1.9 644)
@@ -404,6 +404,8 @@ static void try_to_sync_unused_inodes(vo
        spin_lock(&sb_lock);
        sb = sb_entry(super_blocks.next);
        for (; nr_inodes && sb != sb_entry(&super_blocks); sb = 
sb_entry(sb->s_list.next)) {
+               if (list_empty(&sb->s_dirty))
+                       continue;
                spin_unlock(&sb_lock);
                nr_inodes = try_to_sync_unused_list(&sb->s_dirty, nr_inodes);
                spin_lock(&sb_lock);
@@ -957,8 +959,6 @@ struct inode *igrab(struct inode *inode)
                 */
                inode = NULL;
        spin_unlock(&inode_lock);
-       if (inode)
-               wait_on_inode(inode);
        return inode;
 }
 

>2. If there are any relevant bugs, I may upgrade to kernel 2.4.16 or,
>   eventually, to 2.4.17 once it is released and XFS patches become
>   available. In general, how stable are the developmental XFS
>   releases on SGI's site or as obtained via CVS? In general I don't
>   mind testing a new kernel if the worst that is likely to happen
>   would be a system crash; but serious data corruption is another
>   matter entirely. Of course, I realize that any testing is
>   completely at my own risk.

The CVS tree is bleeding edge with minimal testing, it has not been run
through a full QA check.  Since Marcelo seems to be making sure that
2.4.17 is stable before it is released I would recommend waiting for
the 2.4.17 kernel and the XFS split patches, there are too many bugs in
2.4.16 base for my liking.  I will not generate the split patches until
3-4 days after 2.4.17-XFS hits the CVS tree, so the code has gone
through QA before the patches are released.


<Prev in Thread] Current Thread [Next in Thread>