different oops

different oops

[Martin Bürger]

Hi,
I'm using the sources from [1] which I checked out today. When=20
testing the file system with compilebench [2] I traced oops [3]=20
(with 2 cores, SMP), [4] (single core), [5] (no smp) and [6]=20
(no-preemt).


[1]=20
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
[2] http://oss.oracle.com/~mason/compilebench/
[3] http://rafb.net/p/1hUnky34.html
[4] http://rafb.net/p/kEGqY199.html
[5] http://rafb.net/p/pAHJrV88.html
[6] http://rafb.net/p/tkz92m77.html

Best regards,
--=20
Martin B=C3=BCrger
1024D/27C9019B@www.edu.uni-klu.ac.at/~mbuerger/key.asc
Key fingerprint =3D D10D 97EF 0C32 B337 5A12  0B6C 2D47 7575 27C9 019B
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Chris Mason]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Fri, 2008-10-03 at 18:14 +0200, Martin Bürger wrote:
> Hi,
> I'm using the sources from [1] which I checked out today. When 
> testing the file system with compilebench [2] I traced oops [3] 
> (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6] 
> (no-preemt).
> 

> [1] 
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
> [2] http://oss.oracle.com/~mason/compilebench/
> [3] http://rafb.net/p/1hUnky34.html
> [4] http://rafb.net/p/kEGqY199.html
> [5] http://rafb.net/p/pAHJrV88.html
> [6] http://rafb.net/p/tkz92m77.html

Hello,

This is a long standing bug that so far we've only heard about on gentoo
installs.  Could you please give the attached patch a try against your
sources?

-chris


[-- Attachment #2: flush-on-mount.diff --]
[-- Type: text/x-patch, Size: 1802 bytes --]

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 0be044b..726aaf6 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1482,6 +1482,7 @@ struct btrfs_root *open_ctree(struct super_block *sb,
 	__setup_root(4096, 4096, 4096, 4096, tree_root,
 		     fs_info, BTRFS_ROOT_TREE_OBJECTID);
 
+	filemap_write_and_wait(fs_devices->latest_bdev->bd_inode->i_mapping);
 
 	bh = __bread(fs_devices->latest_bdev,
 		     BTRFS_SUPER_INFO_OFFSET / 4096, 4096);
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index f63cf76..9555408 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -361,8 +361,12 @@ int btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
 
 	list_for_each(cur, head) {
 		device = list_entry(cur, struct btrfs_device, dev_list);
-		if (device->bdev)
+		if (device->bdev) {
+			struct address_space *mapping;
+			mapping = device->bdev->bd_inode->i_mapping;
+			filemap_write_and_wait(mapping);
 			continue;
+		}
 
 		if (!device->name)
 			continue;
@@ -374,6 +378,7 @@ int btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
 			goto error;
 		}
 		set_blocksize(bdev, 4096);
+		filemap_write_and_wait(bdev->bd_inode->i_mapping);
 
 		bh = __bread(bdev, BTRFS_SUPER_INFO_OFFSET / 4096, 4096);
 		if (!bh)
@@ -442,6 +447,8 @@ int btrfs_scan_one_device(const char *path, int flags, void *holder,
 	ret = set_blocksize(bdev, 4096);
 	if (ret)
 		goto error_close;
+
+	filemap_write_and_wait(bdev->bd_inode->i_mapping);
 	bh = __bread(bdev, BTRFS_SUPER_INFO_OFFSET / 4096, 4096);
 	if (!bh) {
 		ret = -EIO;
@@ -951,6 +958,7 @@ int btrfs_rm_device(struct btrfs_root *root, char *device_path)
 			goto out;
 		}
 
+		filemap_write_and_wait(bdev->bd_inode->i_mapping);
 		bh = __bread(bdev, BTRFS_SUPER_INFO_OFFSET / 4096, 4096);
 		if (!bh) {
 			ret = -EIO;

Re: different oops

[Martin Bürger]

On Friday 03 October 2008, Chris Mason wrote:
> On Fri, 2008-10-03 at 18:14 +0200, Martin B=C3=BCrger wrote:
> > Hi,
> > I'm using the sources from [1] which I checked out today. When
> > testing the file system with compilebench [2] I traced oops [3]
> > (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6]
> > (no-preemt).
> >
> >
> > [1]
> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unsta
> >ble.git [2] http://oss.oracle.com/~mason/compilebench/
> > [3] http://rafb.net/p/1hUnky34.html
> > [4] http://rafb.net/p/kEGqY199.html
> > [5] http://rafb.net/p/pAHJrV88.html
> > [6] http://rafb.net/p/tkz92m77.html
>
> Hello,
>
> This is a long standing bug that so far we've only heard about on
> gentoo installs.  Could you please give the attached patch a try
> against your sources?

Here's a trace after having applied the patch [1].

[1] http://rafb.net/p/8zzEfe66.html

--=20
Martin B=C3=BCrger
1024D/27C9019B@www.edu.uni-klu.ac.at/~mbuerger/key.asc
Key fingerprint =3D D10D 97EF 0C32 B337 5A12  0B6C 2D47 7575 27C9 019B
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Chris Mason]

On Fri, 2008-10-03 at 19:10 +0200, Martin B=C3=BCrger wrote:
> On Friday 03 October 2008, Chris Mason wrote:
> > On Fri, 2008-10-03 at 18:14 +0200, Martin B=C3=BCrger wrote:
> > > Hi,
> > > I'm using the sources from [1] which I checked out today. When
> > > testing the file system with compilebench [2] I traced oops [3]
> > > (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6]
> > > (no-preemt).
> > >
> > >
> > > [1]
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unsta
> > >ble.git [2] http://oss.oracle.com/~mason/compilebench/
> > > [3] http://rafb.net/p/1hUnky34.html
> > > [4] http://rafb.net/p/kEGqY199.html
> > > [5] http://rafb.net/p/pAHJrV88.html
> > > [6] http://rafb.net/p/tkz92m77.html
> >
> > Hello,
> >
> > This is a long standing bug that so far we've only heard about on
> > gentoo installs.  Could you please give the attached patch a try
> > against your sources?
>=20
> Here's a trace after having applied the patch [1].
>=20
> [1] http://rafb.net/p/8zzEfe66.html
>=20

The interesting part of this is that every file created by compilebench
is filled by the same pattern 4k of 'a'.

Every corruption in Martin's trace looks the same:

bad tree block start 7016996765293437281 74264576

7016996765293437281 is what we found on disk, the second number is what
we expected to find.  The number we found on disk is what you get when
you have a u64 full of 'a'.

This means that we're overwriting metadata blocks with data blocks.  I'=
m
looking harder.

-chris



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Andrea Gelmini]

2008/10/3 Chris Mason <chris.mason@oracle.com>:
> This is a long standing bug that so far we've only heard about on gentoo
> installs.  Could you please give the attached patch a try against your
> sources?

I've got same problem, with lastest ubuntu, and my own kernel (vanilla).
I can trigger disk copying ~2GB of data from my home to btrfs (65GB
test partition), everytime I try.

It seems easier to trigger when copying files of size > 300MB.

I can give you root access to my laptop if it helps.

Ciao,
Gelma

Re: different oops

[Chris Mason]

On Fri, 2008-10-03 at 19:16 +0200, Andrea Gelmini wrote:
> 2008/10/3 Chris Mason <chris.mason@oracle.com>:
> > This is a long standing bug that so far we've only heard about on gentoo
> > installs.  Could you please give the attached patch a try against your
> > sources?
> 
> I've got same problem, with lastest ubuntu, and my own kernel (vanilla).
> I can trigger disk copying ~2GB of data from my home to btrfs (65GB
> test partition), everytime I try.
> 
> It seems easier to trigger when copying files of size > 300MB.
> 
> I can give you root access to my laptop if it helps.
> 
> Ciao,
> Gelma

Ok are you also on i386 (not 64bit)

-chris

Re: different oops

[Andrea Gelmini]

2008/10/3 Chris Mason <chris.mason@oracle.com>:
> Ok are you also on i386 (not 64bit)
yes.

root@jnb:/home/gelma# head /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 14
model name      : Genuine Intel(R) CPU           T2500  @ 2.00GHz
stepping        : 8
cpu MHz         : 1000.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2


thanks,
Gelma

Re: different oops

[Martin Bürger]

CONFIG_LBD was not set during my tests. After enabling it no errors=20
whatsoever occured executing the same tests.

Regards,
--=20
Martin B=C3=BCrger
1024D/27C9019B@www.edu.uni-klu.ac.at/~mbuerger/key.asc
Key fingerprint =3D D10D 97EF 0C32 B337 5A12  0B6C 2D47 7575 27C9 019B
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Chris Mason]

On Fri, 2008-10-03 at 22:22 +0200, Martin B=C3=BCrger wrote:

[ Btrfs corruptions on i386 ]

> CONFIG_LBD was not set during my tests. After enabling it no errors=20
> whatsoever occured executing the same tests.

Thank you, this is great news.  I had asked Andrea to try the same
thing.  Toei Rei we might have finally tracked down the metadata
corruptions you've been seeing.

CONFIG_LBD turns the sector_t data type from an unsigned long into a
u64.  Btrfs was using it like it was always a u64, and sometimes it was
overflowing.

-chris




--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Andrea Gelmini]

MjAwOC8xMC8zIENocmlzIE1hc29uIDxjaHJpcy5tYXNvbkBvcmFjbGUuY29tPjoKPiBPbiBGcmks
IDIwMDgtMTAtMDMgYXQgMjI6MjIgKzAyMDAsIE1hcnRpbiBCw7xyZ2VyIHdyb3RlOgo+IFRoYW5r
IHlvdSwgdGhpcyBpcyBncmVhdCBuZXdzLiAgSSBoYWQgYXNrZWQgQW5kcmVhIHRvIHRyeSB0aGUg
c2FtZQo+IHRoaW5nLiAgVG9laSBSZWkgd2UgbWlnaHQgaGF2ZSBmaW5hbGx5IHRyYWNrZWQgZG93
biB0aGUgbWV0YWRhdGEKPiBjb3JydXB0aW9ucyB5b3UndmUgYmVlbiBzZWVpbmcuCgpKdXN0IGVu
YWJsaW5nIExCRCBzZWVtcyB0byBmaXggdGhlIHByb2JsZW0gaGVyZSwgdG9vLgoKSSdtIGdvaW5n
IHRvIHRyeSB0byB1c2UgdGhlIGNsb25lZCBwYXJ0aXRpb24gYXMgbXkgbmV3IC8uCklzIHRoZXJl
IHNvbWV0aGluZyBkYW5nZXJvdXMgb3RoZXIgdGhlIEVOT1NQQz8KCkNpYW8sCkdlbG1hCg==

Re: different oops

[Andrea Gelmini]

MjAwOC8xMC80IEFuZHJlYSBHZWxtaW5pIDxhbmRyZWEuZ2VsbWluaUBnbWFpbC5jb20+Ogo+IDIw
MDgvMTAvMyBDaHJpcyBNYXNvbiA8Y2hyaXMubWFzb25Ab3JhY2xlLmNvbT46Cj4+IE9uIEZyaSwg
MjAwOC0xMC0wMyBhdCAyMjoyMiArMDIwMCwgTWFydGluIELDvHJnZXIgd3JvdGU6Cj4+IFRoYW5r
IHlvdSwgdGhpcyBpcyBncmVhdCBuZXdzLiAgSSBoYWQgYXNrZWQgQW5kcmVhIHRvIHRyeSB0aGUg
c2FtZQo+PiB0aGluZy4gIFRvZWkgUmVpIHdlIG1pZ2h0IGhhdmUgZmluYWxseSB0cmFja2VkIGRv
d24gdGhlIG1ldGFkYXRhCj4+IGNvcnJ1cHRpb25zIHlvdSd2ZSBiZWVuIHNlZWluZy4KPgo+IEp1
c3QgZW5hYmxpbmcgTEJEIHNlZW1zIHRvIGZpeCB0aGUgcHJvYmxlbSBoZXJlLCB0b28uCgpEdXJp
bmcgYSBjcCBvZiB+NDBHQiBvZiBkYXRhLCBzb21lIGRlbGV0ZSwgYSBtaXJyb3JkaXIsIHVtb3Vu
dC9tb3VudCwKSSd2ZSBnb3QgdGhlc2U6ClsxMDIxNC45NzI5MjJdIGxlYWYgcmVmIG1pc3MgZm9y
IGJ5dGVuciA2MzI1OTQ0MzIKWzEwMjUwLjQ4MzU1OV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5y
IDY0OTI2MTA1NgpbMTAyNTAuNTUwMjI4XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjQ5MjY1
MTUyClsxMDI1MC41NTE3MzJdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2NDg3ODE4MjQKWzEw
MjUwLjU1MTk1M10gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY0ODc4NTkyMApbMTAyNTAuNTUy
MTc5XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjQ4ODM1MDcyClsxMDI1MC41NTI0MDBdIGxl
YWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2NDg4NDczNjAKWzEwMjUwLjU1MjYxMl0gbGVhZiByZWYg
bWlzcyBmb3IgYnl0ZW5yIDY0ODg1MTQ1NgpbMTAyNTAuNTUyODIzXSBsZWFmIHJlZiBtaXNzIGZv
ciBieXRlbnIgNjQ4ODk2NTEyClsxMDI1MC42NzY1ODFdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVu
ciA2NTI3ODM2MTYKWzEwMjUwLjY3Njk3Ml0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY1NzIx
OTU4NApbMTAyODUuMTIzOTI1XSBfX3JhdGVsaW1pdDogNTQgY2FsbGJhY2tzIHN1cHByZXNzZWQK
WzEwMjg1LjEyMzkzNF0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY0MjM0NzAwOApbMTAyODUu
MTM4NDgwXSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjE3OTM0ODQ4ClsxMDI4NS4xNTEzMjNd
IGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2MTc5OTIxOTIKWzEwMjg1LjE1MTc5Nl0gbGVhZiBy
ZWYgbWlzcyBmb3IgYnl0ZW5yIDY0MjI4MTQ3MgpbMTAyODUuMTUyMzQxXSBsZWFmIHJlZiBtaXNz
IGZvciBieXRlbnIgNjQyMjg1NTY4ClsxMDI4NS4xNTMyODVdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5
dGVuciA2NDIyODk2NjQKWzEwMjg1LjE1NDc5Ml0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY0
MjM5MjA2NApbMTAyODUuMTU1NTI0XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjQyMzk2MTYw
ClsxMDI4NS4xNTY2MjVdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2NDI0MDAyNTYKWzEwMjg1
LjE1NzYxMV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY0MjQwNDM1MgpbMTAzMTguNjg3Nzgy
XSBfX3JhdGVsaW1pdDogMjkgY2FsbGJhY2tzIHN1cHByZXNzZWQKWzEwMzE4LjY4Nzc4OV0gbGVh
ZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY3ODMyNjI3MgpbMTAzMTguNzA0MzA2XSBsZWFmIHJlZiBt
aXNzIGZvciBieXRlbnIgNjc4MzMwMzY4ClsxMDMxOC43MDQ0NzJdIGxlYWYgcmVmIG1pc3MgZm9y
IGJ5dGVuciA2NzgzMzg1NjAKWzEwMzE4LjcyOTk4NV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5y
IDY3ODM0MjY1NgpbMTAzMTguNzU1Mzk0XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjc4MzQ2
NzUyClsxMDMxOC43NjMyMDJdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2NzgzMTM5ODQKWzEw
MzE4Ljc3MzM5MV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY3ODMxODA4MApbMTAzMTguNzcz
NzAyXSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjc4MzU0OTQ0ClsxMDMxOC43NzczOTFdIGxl
YWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2NzgzNTkwNDAKWzEwMzE4Ljc3NzY3NV0gbGVhZiByZWYg
bWlzcyBmb3IgYnl0ZW5yIDY3ODM2MzEzNgpbMTAzNTYuNjY5NDk4XSBfX3JhdGVsaW1pdDogMTEg
Y2FsbGJhY2tzIHN1cHByZXNzZWQKWzEwMzU2LjY2OTUwNV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0
ZW5yIDY2MDUxMjc2OApbMTAzNTYuNjY5ODQ3XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjYw
NTI1MDU2ClsxMDM1Ni42NzAyMDFdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2NjA1MDg2NzIK
WzEwMzU2LjY3MDM1MF0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDY2MDYwMjg4MApbMTAzNTYu
NzE0MTA2XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNjg5Njc2Mjg4ClsxMDM1Ni44MDgwMzZd
IGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA2ODExNTI1MTIKWzEwNDI3LjU3MTE4Ml0gbGVhZiBy
ZWYgbWlzcyBmb3IgYnl0ZW5yIDY4OTA5MDU2MApbMTA2NjguMTgyNjk5XSBsZWFmIHJlZiBtaXNz
IGZvciBieXRlbnIgODc5MDQyNTYwClsxMDY2OC4xODI4NjRdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5
dGVuciA4NzkwNDY2NTYKWzEwNjY4LjE4NzY1OV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDg5
NzU2MDU3NgpbMTA2NjguMjEyODYyXSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgODc2MDMyMDAw
ClsxMDcxMS4zNjc1NjRdIGRldmljZSBmc2lkIDVkNDFjZTVmOTJkM2FkZTUtZmU5MGY3YzZkNDg2
OGM4ZiBkZXZpZCAxCnRyYW5zaWQgMzAyIC9kZXYvbWFwcGVyL1ZHLWJ0cmZzClsxMDgzNS4xOTQx
NjVdIGRldmljZSBmc2lkIDVkNDFjZTVmOTJkM2FkZTUtZmU5MGY3YzZkNDg2OGM4ZiBkZXZpZCAx
CnRyYW5zaWQgMzA4IC9kZXYvbWFwcGVyL1ZHLWJ0cmZzClsxMDkzNi4xODIyMTddIHNwYWNlIGlu
Zm8gZnVsbCAxClsxMTE2NS4wOTk5MDFdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA0NTAwMTEx
MzYKWzExMTY1LjE1OTg1OV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDQ2MzMzNTQyNApbMTEx
NjUuMjU2NTM0XSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNDYzODUxNTIwClsxMTE2NS4yNTkz
OTddIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA0NjM4MzEwNDAKWzExMTY1LjI2ODkzMV0gbGVh
ZiByZWYgbWlzcyBmb3IgYnl0ZW5yIDQ2NzA3OTE2OApbMTE5MTMuNTAxOTE0XSBsZWFmIHJlZiBt
aXNzIGZvciBieXRlbnIgNDQ0MTcwMjQwClsxMTkxMy41MDIyMTddIGxlYWYgcmVmIG1pc3MgZm9y
IGJ5dGVuciA0NDQxOTA3MjAKWzExOTEzLjUxOTc2MV0gbGVhZiByZWYgbWlzcyBmb3IgYnl0ZW5y
IDQ0NDE0OTc2MApbMTE5MTMuNjIxNDgxXSBsZWFmIHJlZiBtaXNzIGZvciBieXRlbnIgNDY5NjY3
ODQwClsxMTkxMy42MjE3MzhdIGxlYWYgcmVmIG1pc3MgZm9yIGJ5dGVuciA0Njk2OTY1MTIKCkNp
YW8sCkdlbG1hCg==

Re: different oops

[Chris Mason]

On Sat, Oct 04, 2008 at 02:15:53AM +0200, Andrea Gelmini wrote:
> 2008/10/4 Andrea Gelmini <andrea.gelmini@gmail.com>:
> > 2008/10/3 Chris Mason <chris.mason@oracle.com>:
> >> On Fri, 2008-10-03 at 22:22 +0200, Martin B=FCrger wrote:
> >> Thank you, this is great news.  I had asked Andrea to try the same
> >> thing.  Toei Rei we might have finally tracked down the metadata
> >> corruptions you've been seeing.
> >
> > Just enabling LBD seems to fix the problem here, too.
>=20
> During a cp of ~40GB of data, some delete, a mirrordir, umount/mount,
> I've got these:
> [10214.972922] leaf ref miss for bytenr 632594432

These are safe, I'm removing them.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Chris Mason]

On Sat, Oct 04, 2008 at 12:09:08AM +0200, Andrea Gelmini wrote:
> 2008/10/3 Chris Mason <chris.mason@oracle.com>:
> > On Fri, 2008-10-03 at 22:22 +0200, Martin B=FCrger wrote:
> > Thank you, this is great news.  I had asked Andrea to try the same
> > thing.  Toei Rei we might have finally tracked down the metadata
> > corruptions you've been seeing.
>=20
> Just enabling LBD seems to fix the problem here, too.
>=20
> I'm going to try to use the cloned partition as my new /.
> Is there something dangerous other the ENOSPC?

We don't have known big bugs right now, but you'll need to use another
=46S on /boot.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: different oops

[Jeff Schroeder]

On Fri, Oct 3, 2008 at 5:31 PM, Chris Mason <chris.mason@oracle.com> wrote:
>
> We don't have known big bugs right now, but you'll need to use another
> FS on /boot.

Is a patch to grub and/or grub2 on the roadmap for r/o btrfs support once the
disk format stabilizes?

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

Re: different oops

[Chris Mason]

On Fri, 2008-10-03 at 20:41 -0700, Jeff Schroeder wrote:
> On Fri, Oct 3, 2008 at 5:31 PM, Chris Mason <chris.mason@oracle.com> wrote:
> >
> > We don't have known big bugs right now, but you'll need to use another
> > FS on /boot.
> 
> Is a patch to grub and/or grub2 on the roadmap for r/o btrfs support once the
> disk format stabilizes?
> 

Yes, it actually wouldn't be a bad project for someone looking to get
started on btrfs.

-chris

Re: different oops

[Andrea Gelmini]

2008/10/4 Chris Mason <chris.mason@oracle.com>:
>> I'm going to try to use the cloned partition as my new /.
>> Is there something dangerous other the ENOSPC?
>
> We don't have known big bugs right now, but you'll need to use another
> FS on /boot.

I use initd, so no problem.
Anyway, I started using btrfs for my /home (before it was Reiserfs3).
Well, after few days of usage, the good news is about no problem like
crash, file corruption, and so on. It also worked well with TuxOnIce,
with a lot of suspend/resume cycle. The bad news is about load
average. In normal session (WindowMaker, Firefox, Kopete, Skype,
Konsole, Evince, Azureus, Evolution, K3B) I've a lot higher load
average respect Reiserfs3. The worst is using mirrordir to backup
/home on external device (load avg > 10).
Is it a normal work in progress, or does it happens only to me?
My /home is over dm-crypt, by the way.

Thanks a lot for your time,
Gelma

Re: different oops

[Chris Mason]

On Tue, 2008-10-07 at 13:31 +0200, Andrea Gelmini wrote:
> 2008/10/4 Chris Mason <chris.mason@oracle.com>:
> >> I'm going to try to use the cloned partition as my new /.
> >> Is there something dangerous other the ENOSPC?
> >
> > We don't have known big bugs right now, but you'll need to use another
> > FS on /boot.
> 
> I use initd, so no problem.
> Anyway, I started using btrfs for my /home (before it was Reiserfs3).
> Well, after few days of usage, the good news is about no problem like
> crash, file corruption, and so on. It also worked well with TuxOnIce,
> with a lot of suspend/resume cycle. The bad news is about load
> average. In normal session (WindowMaker, Firefox, Kopete, Skype,
> Konsole, Evince, Azureus, Evolution, K3B) I've a lot higher load
> average respect Reiserfs3. The worst is using mirrordir to backup
> /home on external device (load avg > 10).
> Is it a normal work in progress, or does it happens only to me?
> My /home is over dm-crypt, by the way.
> 

Btrfs does use more cpu than reiserfs will because of the checksumming,
and you have dm-crypt using CPU as well.  Is the system unresponsive
during the high load?

The load on linux is somewhat strange because it reflects both the
number of procs waiting on IO and the number using CPU.  Running top and
looking at the process states will help figure out which one is the
cause 'D' means IO and 'R' means CPU.

-chris

Re: different oops

[Andrea Gelmini]

2008/10/7 Chris Mason <chris.mason@oracle.com>:
> Btrfs does use more cpu than reiserfs will because of the checksumming,
I don't think this is the problem. I mean, in same condition, with Reiserfs3,
I stay between 0.85 - 1.50 load avg.
Now I easily go from 5 - 10.
It's hard to believe so much overhead just for CRC.
Anyway, can I safely mount my /home disabling CRC? I read it about time before.

> and you have dm-crypt using CPU as well.  Is the system unresponsive
> during the high load?
not exactly. it became slugghish. so, things that was zero-wait, now
may have seconds of delay.
something similar a "make -j"...
now I have doubled the space of the logical volume, and things seems
better (now, loadavg is not going over 4, doing
the mirrordir test).
anyway, I have to use it almost one day, to have a clear idea.

> The load on linux is somewhat strange because it reflects both the
> number of procs waiting on IO and the number using CPU.  Running top and
> looking at the process states will help figure out which one is the
> cause 'D' means IO and 'R' means CPU.
yes.
well, the strange things is the system is faster than before doing
write. but looking at top (I use htop, but it doesn't matter), it
doesn't seem something process related, but seems kernel alway busy
doing something I can't figure out.

are there some tests I can run just to have some raw number to try to
explain this?

thanks a lot for your time,
Gelma

Re: different oops

[Chris Mason]

On Tue, 2008-10-07 at 17:04 +0200, Andrea Gelmini wrote:
> 2008/10/7 Chris Mason <chris.mason@oracle.com>:
> > Btrfs does use more cpu than reiserfs will because of the checksumming,
> I don't think this is the problem. I mean, in same condition, with Reiserfs3,
> I stay between 0.85 - 1.50 load avg.
> Now I easily go from 5 - 10.
> It's hard to believe so much overhead just for CRC.
> Anyway, can I safely mount my /home disabling CRC? I read it about time before.

Yes, you can mount -o nodatasum

> 
> > and you have dm-crypt using CPU as well.  Is the system unresponsive
> > during the high load?
> not exactly. it became slugghish. so, things that was zero-wait, now
> may have seconds of delay.
> something similar a "make -j"...
> now I have doubled the space of the logical volume, and things seems
> better (now, loadavg is not going over 4, doing
> the mirrordir test).
> anyway, I have to use it almost one day, to have a clear idea.

Ok, its important to understand which parts of the FS are using so much
cpu.  It is pretty easy to tell based on the output of top (which procs
are consuming the most time).

> 
> > The load on linux is somewhat strange because it reflects both the
> > number of procs waiting on IO and the number using CPU.  Running top and
> > looking at the process states will help figure out which one is the
> > cause 'D' means IO and 'R' means CPU.
> yes.
> well, the strange things is the system is faster than before doing
> write. but looking at top (I use htop, but it doesn't matter), it
> doesn't seem something process related, but seems kernel alway busy
> doing something I can't figure out.
> 
> are there some tests I can run just to have some raw number to try to
> explain this?

Which procs are using the most time in top?

-chris

Re: different oops

[Andrea Gelmini]

2008/10/7 Chris Mason <chris.mason@oracle.com>:
> Ok, its important to understand which parts of the FS are using so much
> cpu.  It is pretty easy to tell based on the output of top (which procs
> are consuming the most time).

Well, it's not about a process doing something intensive, but
different procs doing a little i/o.
Azurues (reading and writing no more than 40KB/s), Firefox (I've got
cache in tmpfs, but history & co. in ~/.mozilla), IM (logs chat), Vim,
and so on.
So, usually, I see process in D (for too much time, I would say).
I though "maybe it takes too long to find free space", I was at 80% full.
A couple of hours ago I doubled the free space (now I am using the 33%
of the partition). Things are not perfect, but a lot better.
Loadavg is < 1, and things seems responsive.

Anyway, I'll wait some days and I'll see. I need to use it for
sometime to have a good idea.

Less free space could be the problem?

Ciao,
Gelma

Re: different oops

[Andrea Gelmini]

2008/10/7 Andrea Gelmini <andrea.gelmini@gmail.com>:
> Less free space could be the problem?

Well, I can say more free space makes load avg lesser.
Anyway, now I've got a freeze (you can see the dmesg in attach).
It seems related with che last file I'm downloading with Azureus.
If I restart it (azureus), after a while it crashes again (kernel).

Well, is it enough to remove the file? Or move it? Or is it better if
I restore my backup?

Thanks a lot,
Gelma

Re: different oops

[Chris Mason]

On Wed, 2008-10-08 at 23:51 +0200, Andrea Gelmini wrote:
> 2008/10/7 Andrea Gelmini <andrea.gelmini@gmail.com>:
> > Less free space could be the problem?
> 
> Well, I can say more free space makes load avg lesser.
> Anyway, now I've got a freeze (you can see the dmesg in attach).
> It seems related with che last file I'm downloading with Azureus.
> If I restart it (azureus), after a while it crashes again (kernel).
> 
> Well, is it enough to remove the file? Or move it? Or is it better if
> I restore my backup?

Please post the crash, that's the easiest way to figure things out.

-chris

Re: different oops

[Andrea Gelmini]

2008/10/9 Chris Mason <chris.mason@oracle.com>:
> Yan,
>
> Can these leaf ref miss warnings trigger corruptions?  I thought not but
> its clear there is some metadata corruption here:
>
> Andrea, how exactly did you trigger this?

Nothing in particular, usual work session on my laptop.
It seems to be it was a problem with a newly created torrent file.
Well, no deep debug, simply some minutes after
Azureus started it crashed (kernel), always.
So I take new last file, copyed to tmpfs (without errors reading), and
re-copyed to btrfs.
The problem disappeared. Part of file was corrupted, but there was the
crash, azureus caching, and so on.
Anyway, comparing my /home with the external backup, I found no problem.

'Til now I have no evidence of data/metadata corruption.

Thanks a lot,
Andrea

Re: different oops

[Andrea Gelmini]

2008/10/9 Yan Zheng <zheng.yan@oracle.com>:
> Andrea, did you create swap file on btrfs?
No, but Azureus (see my other email) plays a lot with holes.

Thanks a lot,
Andrea

Re: different oops

[Andrea Gelmini]

2008/10/10 Andrea Gelmini <andrea.gelmini@gmail.com>:
> 2008/10/9 Yan Zheng <zheng.yan@oracle.com>:
>> Andrea, did you create swap file on btrfs?
> No, but Azureus (see my other email) plays a lot with holes.

Well, I try to extend my previous reply (in the meanwhile it crashed
again (kernel) with a newly added file).
I've got no "unsual" usage of my btrfs partition (is a /home on a
logical volume, over a dm-crypted /dev/sda3 partition).
The process able to trigger the crash is Azureus.
The "unusual" work of it, respect the other programs I run, is its
creation of file with lots of hole.
When I start to download movies (ehm... iso images of linux
distribution...), it does this:
first chunk (1~4MB) --- big big big holes (for ~1GB) --- last chunk (1~4MB)
then, while downloading, it replaces holes with real data (in a random
way, of course).

Well, I could try to allocate all space at the time creation.
Anyway, today I'll switch to 2.6.27 and new btrfs layout, so I
postpone this try after.

Thanks a lot for your time,
Andrea