public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@namesys.com>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, hch@lst.de, jack@suse.cz, mason@suse.com
Subject: Re: ext2 FS corruption with 2.5.59.
Date: Sat, 25 Jan 2003 15:36:07 +0300	[thread overview]
Message-ID: <20030125153607.A10590@namesys.com> (raw)
In-Reply-To: <20030124225320.5d387993.akpm@digeo.com>

Hello!

On Fri, Jan 24, 2003 at 10:53:20PM -0800, Andrew Morton wrote:
> > Ok, So far simplest way of reproducing for me was this:
> > mkdir /mnt
> > fsstress -p 10 -n1000000 -d /mnt &
> > fsx -c 1234 testfile
> > Now look at fsx output. When it says about "truncating to largest ever: 0x3ffff",
> > wait 10 more seconds and if nothing happens, ^C the fsx,
> > run "rm -rf testfile*"
> > now run fsx again
> > and so on until it fails.
> > Last time it took me three iterations to reproduce.
> Well I've been running this for a couple of hours:
> 	#!/bin/sh
> 	while true
> 	do
> 	        fsstress -p 10 -n1000000 -d . &
> 	        fsx-linux -c 1234 testfile &
> 	        sleep 180
> 	        killall fsx-linux fsstress
> 	        sleep 1
> 	done

Hm. I do not kill my fsstress.
Here is my version:

#!/bin/bash
mke2fs /dev/hdb2
mount /dev/hdb2 /mnt -t ext2
cd /mnt
/tests/fsstress -p10 -n 1000000 -d . &
while /tests/fsx -c 1234 -N60309 testfile ; do rm -rf testfile*; done

> So I'm going to have to ask you to investigate further.  Does it happen on
> other machines?  Other filesystems?  Older kernels?  That sort of thing.

Ok. I am able to reproduce that same thing on dual Pentium4 2.2GHz (HT enabled), 512M RAM.
My testing reveals that 2.5.50, 2.5.52 and 2.5.53 do not have the problem.
2.5.54, 2.5.55, 2.5.59 have the problem.
ext3 and reiserfs do not show this problem.
Looking through 2.5.54, I found that changeset named "[PATCH] quota locking update" forwarded by you
is the cause for the problem.
(also by reviewing the changeset it became clear that in order to succesfully reproduce the
problem one must have CONFIG_QUOTA to be disabled).
This small patch below fixes the problem for me (just reverts back part of quota locking patch in fact).
Also I think that taking BKL just to update some inode accounting stuff is kind of expensive,
so certainly better solution must exist.

===== include/linux/quotaops.h 1.13 vs edited =====
--- 1.13/include/linux/quotaops.h	Wed Jan  1 05:44:36 2003
+++ edited/include/linux/quotaops.h	Sat Jan 25 14:52:57 2003
@@ -175,7 +175,9 @@
 #define DQUOT_TRANSFER(inode, iattr)		(0)
 extern __inline__ int DQUOT_PREALLOC_SPACE_NODIRTY(struct inode *inode, qsize_t nr)
 {
+	lock_kernel();
 	inode_add_bytes(inode, nr);
+	unlock_kernel();
 	return 0;
 }
 
@@ -188,7 +190,9 @@
 
 extern __inline__ int DQUOT_ALLOC_SPACE_NODIRTY(struct inode *inode, qsize_t nr)
 {
+	lock_kernel();
 	inode_add_bytes(inode, nr);
+	unlock_kernel();
 	return 0;
 }
 
@@ -201,7 +205,9 @@
 
 extern __inline__ void DQUOT_FREE_SPACE_NODIRTY(struct inode *inode, qsize_t nr)
 {
+	lock_kernel();
 	inode_sub_bytes(inode, nr);
+	unlock_kernel();
 }
 
 extern __inline__ void DQUOT_FREE_SPACE(struct inode *inode, qsize_t nr)

Bye,
    Oleg

  reply	other threads:[~2003-01-25 20:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-23 12:38 ext2 FS corruption with 2.5.59 Oleg Drokin
2003-01-23 14:09 ` Hugh Dickins
2003-01-23 14:26   ` Oleg Drokin
2003-01-23 14:39     ` Oleg Drokin
2003-01-24 10:32 ` Andrew Morton
2003-01-24 12:39   ` Oleg Drokin
2003-01-25  6:53     ` Andrew Morton
2003-01-25 12:36       ` Oleg Drokin [this message]
2003-01-25 23:13         ` Andrew Morton
2003-01-26  9:25           ` Oleg Drokin
2003-01-26  3:04         ` Andrew Morton
2003-01-26  3:28           ` William Lee Irwin III
2003-01-26  3:46             ` Andrew Morton
2003-01-26  4:14               ` William Lee Irwin III
2003-01-26  5:10                 ` Andrew Morton
2003-01-27 22:59                   ` Stephen Hemminger
2003-01-27 23:59                     ` William Lee Irwin III
2003-01-26 11:11           ` Anton Blanchard
2003-01-26 11:23             ` Andrew Morton
2003-01-28 13:50   ` Christoph Hellwig

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=20030125153607.A10590@namesys.com \
    --to=green@namesys.com \
    --cc=akpm@digeo.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mason@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox