Can anyone help me debug more on this btrfs bug under openSUSE 12.1 kernel 3.1.2?

I see this bug frequently now. because I’m a Desktop user, can anyone teach me the command you need or I need to generate more related outputs so that this problem can be solved?

Btrfs-* related process, 2 or more, always ate up my cpu. and computer freeze.

FDISK:

inux:/home/dc/Kernel # LANG=en.US fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0004746f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048     4208639     2103296   82  Linux swap / Solaris
/dev/sda2   *     4209030     5237189      514080   83  ext4 /boot
/dev/sda3         5237190  1748723444   871743127+   5  Extended
/dev/sda4      1748723712  1953523711   102400000    7  HPFS/NTFS/exFAT
/dev/sda5       109081413   724724279   307821433+  83  btrfs /home
/dev/sda6         5237316   109081349    51922017   83  btrfs /root
/dev/sda7       808615936  1748721663   470052864   83  btrfs /not use

Partition table entries are not in disk order

And I/O Top:

http://www.ttiftt.com/di-6VVM.png

Hello,

Quite a lot of google results with similar issues on more platforms but it seems that your problem might be related to this: New: High iowait in openSUSE 12.1, due to Snapper default config - opensuse-bugs.opensuse.org - ArchiveOrange

Just see if this is the case and configure that snapper package according to the recommendations there. Preferably from a different computer since if the btrfs syncing will start again during your session the computer will freeze again (I saw on other posts that after some time it will unfreeze again).

Pay attention to one of the last posts related to firefox / chromium.

I hope this fixes your problem.

Cheers.

PS
I tried looking to the bugzilla links for more info but for some reason I always get requested to confirm an e-mail - weird stuff since I do not have an account there - maybe it works for you.

Hi,

That bug was reported by me. all the things mentioned there can be used to extenuate but not eliminate this weird bug.

and the Novell people still give me no final answer on it.

So I still need help on debug this bug further.

MargueriteSu wrote:
> That bug was reported by me. all the things mentioned there can be used
> to extenuate but not eliminate this weird bug.
>
> and the Novell people still give me no final answer on it.
>
> So I still need help on debug this bug further.

I would suggest you post a summary and a link to the bug to the
opensuse-kernel mailing list. And ask nicely whether anybody is
investigating it. There are developers there who can take some action.

HTH, Dave

MargueriteSu wrote:
> So I still need help on debug this bug further.

Oh, and you also need to go back to the “Terrible iowait issue on
openSUSE 12.1. Is this btrfs related ?” thread and point out that you
have diagnosed the problem and get Bartu5 to confirm your bug report.

I’ve done this: [opensuse-kernel] btrfs high IO waiting](http://lists.opensuse.org/opensuse-kernel/2012-01/msg00003.html)

I don’t how to update mailing list, cause I seldom use it.

I compile kernel-3.2-rc7 using Our Global Moderator jdmcdaniel3’s S.G.T.B and S.A.K.C.

While I replace fs/btrfs with fs/btrfs from Btrfs filesystem’s core developer Mason’s git repository.

It works amazing! he added a btrfs-delay-m process, it increases average cpu i/o in the first seconds, maybe that process is used for better schedule or something, but it sucessfully concentrate cpu power on important things you’re doing instead of flooding cpu with all at once.

and more amazing thing is that cpu usage is nearly zero when free time.

I’ll continuously test it. And I’m working on applying SuSE’s patch sets to this kind of kernel I created. these patches are all for 3.1 series. so I have to regenerate them all. it’ll take some time. but I hope before Feb I can supply such a self repository for others using btrfs like me. Then you can update from repository. the Nvidia card driver will be also provided to co-exist with this kernel.

I hope SuSE could quickly push an update 3.2-rc7 with all its patches applied. then everyone using btrfs can use dkms method mentioned by mason on btrfs wiki to keep their btrfs kernel parts up to date. because after 3.1, there’s a Security.h patch applies globally, so that dkms will surely fail if you compile the most recent btrfs against it.

Anyway I’ll keep updating this post to tell you my work. maybe this is the final answer finally.

MargueriteSu wrote:
> MargueriteSu;2425823 Wrote:
>> I’ve done this: ‘[opensuse-kernel] btrfs high IO waiting’
>> (http://lists.opensuse.org/opensuse-kernel/2012-01/msg00003.html)

Well done!

> I don’t how to update mailing list, cause I seldom use it.

You just reply to a message. (Use the reply-list or reply-all feature of
your mail client). I’m not sure why you hadn’t had any replies to your
message; perhaps because you posted it yesterday evening, European time,
after everybody had left work. I just posted a reply and hopefully
somebody will now notice the issue.

> I compile kernel-3.2-rc7 using Our Global Moderator jdmcdaniel3’s
> ‘S.G.T.B’ (http://tinyurl.com/3pn8anr) and ‘S.A.K.C’
> (http://tinyurl.com/6y8upm5).
>
> While I replace fs/btrfs with fs/btrfs from Btrfs filesystem’s core
> developer Mason’s git repository.
>
> It works amazing! he added a btrfs-delay-m process, it increases
> average cpu i/o in the first seconds, maybe that process is used for
> better schedule or something, but it sucessfully concentrate cpu power
> on important things you’re doing instead of flooding cpu with all at
> once.
>
> and more amazing thing is that cpu usage is nearly zero when free
> time.

That’s very good news. I suggest adding that to your bug report and the
kernel list. Those are the places the developers look at, not here.

> I’ll continuously test it. And I’m working on applying SuSE’s patch
> sets to this kind of kernel I created. these patches are all for 3.1
> series. so I have to regenerate them all. it’ll take some time. but I
> hope before Feb I can supply such a self repository for others using
> btrfs like me. Then you can update from repository. the Nvidia card
> driver will be also provided to co-exist with this kernel.
>
> I hope SuSE could quickly push an update 3.2-rc7 with all its patches
> applied. then everyone using btrfs can use dkms method mentioned by
> mason on btrfs wiki to keep their btrfs kernel parts up to date. because
> after 3.1, there’s a Security.h patch applies globally, so that dkms
> will surely fail if you compile the most recent btrfs against it.

The current Kernel:HEAD already appears to be 3.2-rc7, so I suggest that
the best strategy is to get the kernel developers to update the btrfs or
to fork off of the KOTD. I don’t think there’s a lot of point in a
private repository.

<https://build.opensuse.org/project/show?project=Kernel%3AHEAD>

<https://build.opensuse.org/package/live_build_log?arch=x86_64&package=kernel-default&project=Kernel%3AHEAD&repository=standard>

3.2 may become the kernel for opensuse 12.2. But opensuse won’t change
the kernel for 12.1, except by issuing bugfix patches. If its possible
to fix btrfs by patching the current kernel, they may do that. Best to
talk to them on the mailing list.

> Anyway I’ll keep updating this post to tell you my work. maybe this is
> the final answer finally.

Hello again,

Sorry I did not notice that the post I mentioned was actually by you. :slight_smile:

I looked more into this, since this year I will have to make a new server and I was looking for options for the fs I could use, but more I read about btrfs, more I tend not to use it.

Though it refers to older kernel this does not look quite well, especially for the applications you mentioned (firefox) but also for databases: https://btrfs.wiki.kernel.org/articles/g/o/t/Gotchas.html and they blame it on file fragmentation (this is kinda new to linux world :slight_smile: )

I also noticed that on this ppa the sync fsync were actually disabled because of the slow-downs: https://launchpad.net/~brian-rogers/+archive/btrfs

Similar issues with yours: high CPU usage and low perf – Linux BTRFS

An one year thread discussion about it on gentoo forums: https://forums.gentoo.org/viewtopic-t-838889-postdays-0-postorder-asc-start-0.html

Cheers and good luck.

Sorry for digging this out. but I closed my bug by giveing a link pointing here.

If you tend to use database on server, please certainly not use btrfs. because of the famous fragmentation, fsync bugs.

well, high CPU bug seems to be fixed finally.

but others remain like Phoronix’s most famous five-time prediction of coming out a btrfs fdisk tool. I’m a finance analyst, to me, if a certainly coming out thing is predicted five times without actually coming out, it is not a prediction, it’s a lie.

On 02/27/2012 01:26 AM, MargueriteSu wrote:
> I’m a finance analyst, to me, if a
> certainly coming out thing is predicted five times without actually
> coming out, it is not a prediction, it’s a lie.

+1 !!


DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

On 02/27/2012 04:19 AM, DenverD wrote:
> On 02/27/2012 01:26 AM, MargueriteSu wrote:
>> I’m a finance analyst, to me, if a
>> certainly coming out thing is predicted five times without actually
>> coming out, it is not a prediction, it’s a lie.

I just figure that btrfs is the filesystem of the future, and it always will be.

On 2012-02-27 22:51, Larry Finger wrote:

> I just figure that btrfs is the filesystem of the future, and it always
> will be.

But not of the present, so I will not use it till the future reaches us >:-P


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)