All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: Marek Otahal <markotahal@gmail.com>
Cc: Daniel J Blueman <daniel.blueman@gmail.com>,
	Chris Mason <chris.mason@oracle.com>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Andy Lutomirski <luto@mit.edu>
Subject: Re: kernel BUG at fs/btrfs/inode.c:4676!
Date: Fri, 10 Jun 2011 16:52:36 -0400	[thread overview]
Message-ID: <4DF28414.8090601@redhat.com> (raw)
In-Reply-To: <201106102043.19025.markotahal@gmail.com>

On 06/10/2011 02:43 PM, Marek Otahal wrote:
> On Friday 10 of June 2011 15:33:20 Josef Bacik wrote:
>> On 06/09/2011 10:06 PM, Daniel J Blueman wrote:
>>> On 10 June 2011 09:57, Andy Lutomirski <luto@mit.edu> wrote:
>>>> On 06/06/2011 06:19 AM, Marek Otahal wrote:
>>>>>
>>>>> Hello,
>>>>> the issue happens every time when i have to hard power-off my notebook
>>>>> (suspend problems).
>>>>> With kernel 2.6.39 the partition is unmountable, solution is to boot
>>>>> 2.6.38 kernel which
>>>>> 1/ is able to mount the partition,
>>>>> 2/ by doing that fixes the problem so later .39 (after clean shutdown) can
>>>>> mount it also.
>>>>
>>>> Same problem here.  Mounting with 2.6.38 says:
>>>>
>>>> [   41.906259] Btrfs loaded
>>>> [   41.906747] device fsid e040a9d60da49596-66c0275e348878bf devid 1 transid
>>>> 69217 /dev/mapper/vg_midnight_ssd-home
>>>> [   41.908767] btrfs: disk space caching is enabled
>>>> [   42.232185] btrfs: unlinked 17 orphans
>>>> [   42.232189] btrfs: truncated 2 orphans
>>>>
>>>> dmesg in 2.6.39.1 says:
>>> []
>>>> [   15.004255] kernel BUG at fs/btrfs/inode.c:4676!
>>> []
>>>
>>> I've been experiencing the same issue also.
>>>
>>> Josef/Chris, would an metadata snapshot or full block snapshot help
>>> debug this regression? I can probably setup a small testcase to
>>> trigger this.
>>>
>>
>> If you can come up with a testcase to reproduce I would love you forever
>> ;).  If I get done what I wanted to do today I will try and reproduce.
>> Thanks,
>>
>> Josef
>>
> ...I was getting ready for you eternal love, Josef :P...but I can't reproduce it 100%, like 70% success-rate. 
> 
> The test-case is quite easy, 
> 1. mount the FS, just with compress-force=lzo option // I didn't try without, but on my other btrfs partition that doesn't use compression the err never happened ...so, can the others who experience the bug confirm compress=lzo used?   
> 2. cd to it & create a file (not sure if needed)
> 3. hard power-off
> 
> To reproduce my tests: 
> dd /dev/zero /btrfstest bs=1M count=256 (min required for default mksf.btrfs)
> losetup /dev/loop0 /btrfstest
> mkfs.btrfs /dev/loop0
> mount -o compress-force=lzo /dev/loop0 /mnt/tmp
> vim /mnt/tmp/hello.txt
> ---power off!

How long do you wait between these two steps?  I've not been able to
reproduce this and I've done it maybe 5 times.  Either I've fixed it in
my tree (yay!) or I'm doing something wrong (boo!).  Thanks,

Josef

  parent reply	other threads:[~2011-06-10 20:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-06 10:19 kernel BUG at fs/btrfs/inode.c:4676! Marek Otahal
2011-06-08 18:43 ` Marek Otahal
2011-06-09 15:39 ` Jan Steffens
2011-06-10  1:57 ` Andy Lutomirski
2011-06-10  2:06   ` Daniel J Blueman
2011-06-10 13:33     ` Josef Bacik
     [not found]       ` <201106102043.19025.markotahal@gmail.com>
2011-06-10 18:55         ` Andrew Lutomirski
2011-06-10 20:52         ` Josef Bacik [this message]
2011-06-10 21:52           ` Marek Otahal
2011-06-22 16:09             ` Josef Bacik
2011-07-20  6:05               ` David Woodhouse
2011-07-20  8:44                 ` Chris Mason
2011-07-20 14:37                   ` David Woodhouse
2011-09-17 19:13 ` Stephane Chazelas

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=4DF28414.8090601@redhat.com \
    --to=josef@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=daniel.blueman@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=markotahal@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.