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
next prev parent 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