Bug 845628

Summary:	BTRFS: stalls and phases of massive disk access
Product:	[openSUSE] openSUSE 13.1	Reporter:	Elmar Stellnberger <estellnb>
Component:	Kernel	Assignee:	David Sterba <dsterba>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Critical
Priority:	P5 - None	CC:	dsterba, jeffm
Version:	RC 1
Target Milestone:	---
Hardware:	i686
OS:	SUSE Other
Whiteboard:	btrfs:performance
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	snapper configuration files

Description Elmar Stellnberger 2013-10-12 20:57:33 UTC

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Firefox/24.0

While btrfs works well with oS 13.1 RC1 x86_64 I have run into bad problems with btrfs on an i686 machine. Perhaps the issue may be linked to declaring /etc as an own subroot. The symptoms are like follows:
* a phase of massive disk access lasting for a minute or more
* a stall phase where it seems to do nothing
  At first the problem was triggered on every opening of a file dialogue (file dialogue of kcrashhandler as well as the file dialogue of firefox). Also disk access in common did seem to last longer than normally.
  Now on reboot I have a total system freeze however with num-lock still working.

Reproducible: Always

Comment 1 David Sterba 2013-10-15 12:20:20 UTC

This is probably caused by fragmentation, but there is not enough information to support that, the general symptoms match.

The file dialog may want to display mountpoints or other information based on files in /etc/ -- if the directory is fragmented due to being a subvolume.

Do you use snapper to maintain the /etc/ subvolume? If yes, what's the config?

Comment 2 Elmar Stellnberger 2013-10-15 12:35:00 UTC

Created attachment 563499 [details]
snapper configuration files

yes, snapper seems to be installed.

Comment 3 Elmar Stellnberger 2013-11-15 16:38:58 UTC

Actually a DUP of the DBUS bug. After applying the same fixes as with Bug 845287 I could happily boot into the btrfs-installation. Nothing wrong with btrfs. The cause for the issue apparently was a misconfigured DBUS.

*** This bug has been marked as a duplicate of bug 845287 ***