Re: [PATCH 0/9] btrfs: bug fixes for the tree mod log and small refactorings

On Thu, Mar 11, 2021 at 02:31:04PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > This patchset fixes a couple bugs, in the two first patches, with the tree > mod log code. The remaining patches just move all that code into a separate > file, since it's quite large and ctree.c is hug

[PATCH 0/9] btrfs: bug fixes for the tree mod log and small refactorings

From: Filipe Manana This patchset fixes a couple bugs, in the two first patches, with the tree mod log code. The remaining patches just move all that code into a separate file, since it's quite large and ctree.c is huge as well, and do some small refactorings and cleanups. One of the bugs in par

Re: Btrfs Bug Report

On 2019/7/9 上午8:49, Jungyeon Yoon wrote: > Hi btrfs developers, > > I'm Jungyeon Yoon. I have reported btrfs bug before. > Some of them have marked to fixed thanks to your efforts. > Additionally following bugs seems also fixed as I've checked. > If okay, I would

Re: Btrfs Bug Report

On 2019/7/9 上午8:49, Jungyeon Yoon wrote: > Hi btrfs developers, > > I'm Jungyeon Yoon. I have reported btrfs bug before. > Some of them have marked to fixed thanks to your efforts. > Additionally following bugs seems also fixed as I've checked. > If okay, I would

Btrfs Bug Report

Hi btrfs developers, I'm Jungyeon Yoon. I have reported btrfs bug before. Some of them have marked to fixed thanks to your efforts. Additionally following bugs seems also fixed as I've checked. If okay, I would like to close following bugs, too. https://bugzilla.kernel.org/show_bug.cgi

Re: [GIT PULL] Btrfs bug fixes for 4.12

On 04/26/2017 01:52 PM, fdman...@kernel.org wrote: From: Filipe Manana Hi Chris, Please consider the following changes for the 4.12 merge window. These are all bug fixes and nothing particularly outstanding compared to changes for past merge windows. Thanks. The following changes since commi

[GIT PULL] Btrfs bug fixes for 4.12

From: Filipe Manana Hi Chris, Please consider the following changes for the 4.12 merge window. These are all bug fixes and nothing particularly outstanding compared to changes for past merge windows. Thanks. The following changes since commit a967efb30b3afa3d858edd6a17f544f9e9e46eea: Btrfs:

Re: [GIT PULL] Btrfs bug fixes and improvements for 4.11 (2nd retry)

On Fri, Feb 24, 2017 at 03:25:09AM +, fdman...@kernel.org wrote: From: Filipe Manana Hi Chris, since my previous pull request (sent timely) was either missed or not pulled for some reason I'm not aware of, here I send it again (with one more patch included). The following is taken from the

[GIT PULL] Btrfs bug fixes and improvements for 4.11 (2nd retry)

From: Filipe Manana Hi Chris, since my previous pull request (sent timely) was either missed or not pulled for some reason I'm not aware of, here I send it again (with one more patch included). The following is taken from the former pull request: "Please consider the following changes for the 4.

Re: list/count mismatch warning in rcu_do_batch (possibly triggered by a btrfs bug).

On Tue, Nov 15, 2016 at 10:53:15AM +0200, Nikolay Borisov wrote: > Hello Paul, > > I'm currently going through a crashdump which seems to indicate some > memory corruption, possibly triggered by btrfs. I have several > entries such as : > > [1626691.276310] BUG: Bad page state in process fst

list/count mismatch warning in rcu_do_batch (possibly triggered by a btrfs bug).

Hello Paul, I'm currently going through a crashdump which seems to indicate some memory corruption, possibly triggered by btrfs. I have several entries such as : [1626691.276310] BUG: Bad page state in process fstrim pfn:230ee7 [1626691.276488] page:ea0008c3b9c0 count:0 mapcount:0 mapp

Re: [GIT PULL] Btrfs bug fixes for 4.5

On Mon, Dec 21, 2015 at 05:59:46PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > Hi Chris, > > Please consider the following fixes for the 4.5 merge window. > Nothing outstanding, they are just the usual bug fixes (races, deadlocks, > error paths, etc). These were all sent previous

[GIT PULL] Btrfs bug fixes for 4.5

From: Filipe Manana Hi Chris, Please consider the following fixes for the 4.5 merge window. Nothing outstanding, they are just the usual bug fixes (races, deadlocks, error paths, etc). These were all sent previously to the mailing list and rebased last week against your integration-4.4 branch (s

Re: BTRFS BUG at insert_inline_extent_backref+0xe3/0xf0 while rebalancing

Filipe Manana writes: > Try this (just sent a few minutes ago): > https://patchwork.kernel.org/patch/7463161/ I've been using this patch for a week now, doing two rebalances a day (one per file system) - no problem so far. Thanks! Probably unrelated to this I did experience one reboot without an

Re: BTRFS BUG at insert_inline_extent_backref+0xe3/0xf0 while rebalancing

Hello, Thanks for the super-fast response :). I've installed the patch and shall be waiting. The effects should be visible within a week given daily rebalances of two filesystems. -- _ / __// /__ __ h

Re: BTRFS BUG at insert_inline_extent_backref+0xe3/0xf0 while rebalancing

Unstable) The dump is available at: http://www.modeemi.fi/~flux/btrfs/btrfs-BUG-2015-10-55.txt The log is available as well (stripped some unrelated USB- and firewall logging, showing that last evening there was some kernel task hung for 120 seconds; but it's in another btrfs filesyste

Re: BTRFS BUG at insert_inline_extent_backref+0xe3/0xf0 while rebalancing

Debian Unstable) > > The dump is available at: > > http://www.modeemi.fi/~flux/btrfs/btrfs-BUG-2015-10-55.txt > > The log is available as well (stripped some unrelated USB- and firewall > logging, showing that last evening there was some kernel task hung for > 120 seconds;

BTRFS BUG at insert_inline_extent_backref+0xe3/0xf0 while rebalancing

crashed again after starting the rebalance, and this time there was some information on the kernel log. Kernel version: 4.2.3 (package linux-image-4.2.0-1-amd64 version 4.2.3-1 from Debian Unstable) The dump is available at: http://www.modeemi.fi/~flux/btrfs/btrfs-BUG-2015-10-55.txt The log

Re: [GIT PULL] Btrfs bug fixes

On 09/15/2015 09:43 AM, Holger Hoffstätte wrote: On 09/15/15 14:58, Filipe Manana wrote: On Tue, Sep 15, 2015 at 12:49 PM, Holger Hoffstätte wrote: Hello Filipe, your mail comes just in time as I was typing a mail about this patch: On 09/15/15 04:22, fdman...@kernel.org wrote: Btrfs:

Re: [GIT PULL] Btrfs bug fixes

On 09/15/2015 09:43 AM, Holger Hoffstätte wrote: On 09/15/15 14:58, Filipe Manana wrote: On Tue, Sep 15, 2015 at 12:49 PM, Holger Hoffstätte wrote: Hello Filipe, your mail comes just in time as I was typing a mail about this patch: On 09/15/15 04:22, fdman...@kernel.org wrote: Btrfs:

Re: [GIT PULL] Btrfs bug fixes

On 09/15/15 14:58, Filipe Manana wrote: > On Tue, Sep 15, 2015 at 12:49 PM, Holger Hoffstätte > wrote: >> Hello Filipe, >> >> your mail comes just in time as I was typing a mail about this patch: >> >> On 09/15/15 04:22, fdman...@kernel.org wrote: >>> Btrfs: remove unnecessary locking of cle

Re: [GIT PULL] Btrfs bug fixes

On Tue, Sep 15, 2015 at 12:49 PM, Holger Hoffstätte wrote: > Hello Filipe, > > your mail comes just in time as I was typing a mail about this patch: > > On 09/15/15 04:22, fdman...@kernel.org wrote: >> Btrfs: remove unnecessary locking of cleaner_mutex to avoid deadlock > > While it might se

Re: [GIT PULL] Btrfs bug fixes

Hello Filipe, your mail comes just in time as I was typing a mail about this patch: On 09/15/15 04:22, fdman...@kernel.org wrote: > Btrfs: remove unnecessary locking of cleaner_mutex to avoid deadlock While it might seem to fix this particular problem, it seems there is either a new one o

[GIT PULL] Btrfs bug fixes

From: Filipe Manana Hi Chris, Please consider the following fixes for the 4.3 kernel release candidates. One of them addresses a deadlock introduced in 4.3, another is for a false enospc condition (which I introduced in a 4.2 commit) that can happen either on empty filesystems or filesystems wit

Re: [GIT PULL] More btrfs bug fixes

On Sun, Jul 12, 2015 at 02:50:47AM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Hi Chris, > > Please consider the following changes for the kernel 4.2 release. All > these patches have been available in the mailing list for some time. > > One of the patches is a fix for a regress

[GIT PULL] More btrfs bug fixes

From: Filipe Manana Hi Chris, Please consider the following changes for the kernel 4.2 release. All these patches have been available in the mailing list for some time. One of the patches is a fix for a regression in the delayed references code that landed in 4.2-rc1. Two of them are for issues

Re: [GIT PULL] Btrfs bug fixes

Chris, Have you looked at Omar Sandoval's [PATCH v2 0/5] Btrfs: RAID 5/6 missing device scrub+replace It would be really nice to have these when/if a disk dies... I been running with them since v1 without issue. Thanks Ed Tomlinson On Wednesday, July 1, 2015 1:24:41 PM EDT, Chris Mason wrote

Re: [GIT PULL] Btrfs bug fixes

On Tue, Jun 30, 2015 at 11:20:31PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Hi Chris, > > Please consider the following changes (or a subset at your will in case > they are too many or too large) for the kernel 4.2 release. All these > patches have been available in the mailin

[GIT PULL] Btrfs bug fixes

From: Filipe Manana Hi Chris, Please consider the following changes (or a subset at your will in case they are too many or too large) for the kernel 4.2 release. All these patches have been available in the mailing list for at least 2 weeks. They are all bug fixes and deal with races, crashes,

[PATCH v3] xfstests: generic: add dir fsync test, motivated by a btrfs bug

tree and in the log tree - this is necessary to trigger the +# bug on btrfs. +sync + +touch $SCRATCH_MNT/test_dir/bar +$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/test_dir +$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/test_dir/bar + +_load_flakey_table $FLAKEY_DROP_WRITES +_unmount_flak

[PATCH v2] xfstests: generic: add dir fsync test, motivated by a btrfs bug

d_flakey_table $FLAKEY_ALLOW_WRITES +_mount_flakey + +[ -f $SCRATCH_MNT/foo ] || echo "file foo is missing" +[ -f $SCRATCH_MNT/bar ] || echo "file bar is missing" + +_unmount_flakey + +# In the original btrfs bug, the filesystem consistency check failed here +# because th

[PATCH] xfstests: generic: add dir fsync test, motivated by a btrfs bug

ho "file foo is missing" +[ -f $SCRATCH_MNT/bar ] || echo "file bar is missing" + +_unmount_flakey + +# In the original btrfs bug, the filesystem consistency check failed here +# because the directory inode got set with a wrong i_size by the log replay +# at mount time (dentry 'foo&

[PATCH] xfstests: generic: add test for double msync, motivated by a btrfs bug

last 4Kb of the file. +# This second msync() used to be a no-op for that btrfs bug (and the first fsync +# didn't log the last 4Kb extent as expected too). +$XFS_IO_PROG \ + -c "mmap -w 0 64K" \ + -c "mwrite -S 0xaa 0 4K" \ + -c "mwrite

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Sat, Feb 08, 2014 at 03:10:37PM -0500, Tejun Heo wrote: > Hello, David, Fengguang, Chris. > > On Fri, Feb 07, 2014 at 01:13:06PM -0800, David Rientjes wrote: > > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > > > On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: > > > > On Fri, 7

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

Hi Filipe, > If you disable CONFIG_BTRFS_FS_RUN_SANITY_TESTS, does it still crash? I tried disabling CONFIG_BTRFS_FS_RUN_SANITY_TESTS in the reported 3 randconfigs and they all boot fine. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

Hello, David, Fengguang, Chris. On Fri, Feb 07, 2014 at 01:13:06PM -0800, David Rientjes wrote: > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: > > > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > > > > > [1.625020] BTRFS: selfte

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

> If you disable CONFIG_BTRFS_FS_RUN_SANITY_TESTS, does it still crash? Good idea! I've queued test jobs for that config. However sorry that I'll be offline for the next 2 days. So please expect some delays. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-btrf

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Fri, 7 Feb 2014, Fengguang Wu wrote: > On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: > > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > > > [1.625020] BTRFS: selftest: Running btrfs_split_item tests > > > [1.627004] BTRFS: selftest: Running find delalloc tests > > > [

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Fri, Feb 7, 2014 at 3:10 PM, Chris Mason wrote: > On Fri 07 Feb 2014 07:10:38 AM EST, Fengguang Wu wrote: >> >> On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: >>> >>> On Fri, 7 Feb 2014, Fengguang Wu wrote: >>> [1.625020] BTRFS: selftest: Running btrfs_split_item tests

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Fri 07 Feb 2014 07:10:38 AM EST, Fengguang Wu wrote: On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: On Fri, 7 Feb 2014, Fengguang Wu wrote: [1.625020] BTRFS: selftest: Running btrfs_split_item tests [1.627004] BTRFS: selftest: Running find delalloc tests [2.2891

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > [1.625020] BTRFS: selftest: Running btrfs_split_item tests > > [1.627004] BTRFS: selftest: Running find delalloc tests > > [2.289182] tsc: Refined TSC clocksource calibration

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Fri, 7 Feb 2014, Fengguang Wu wrote: > [1.625020] BTRFS: selftest: Running btrfs_split_item tests > [1.627004] BTRFS: selftest: Running find delalloc tests > [2.289182] tsc: Refined TSC clocksource calibration: 2299.967 MHz > [ 292.084537] kthreadd invoked oom-killer: gfp_mask=0x30

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at (null)

On Fri, Jan 10, 2014 at 12:31 PM, kernel test robot wrote: > Greetings, > > I got the below dmesg and the first bad commit is > > commit 87e612ae9ed2ea886bec151145f4b09b6ee97a10 > Author: Filipe David Borba Manana > AuthorDate: Tue Jan 7 11:47:46 2014 + > Commit: Josef Bacik > Commit

Re: btrfs bug reports?

On Mar 14, 2013, at 9:47 PM, Kyle wrote: > Hi, > > Is the linux-btrfs list interested in receiving bug reports relating to btrfs? > > If so, the following error occurred on a server of mine when copying a large > amount of data to a linear md-RAID formatted as btrfs. The data transfer > hung

btrfs bug reports?

Hi, Is the linux-btrfs list interested in receiving bug reports relating to btrfs? If so, the following error occurred on a server of mine when copying a large amount of data to a linear md-RAID formatted as btrfs. The data transfer hung, and any attempt to kill or strace the copy process hu

Re: BTRFS Bug

On Tue, Nov 20, 2012 at 09:25:02PM +0800, Ross Moore wrote: > Strange. Does that imply a problem with disks or disk cables physically? > Our just the data rather than the metadata? > It seems to be a kernel bug since another user also reported it sometime ago. > I've compiled the latest btrfs-to

Re: BTRFS Bug

On Tue, Nov 20, 2012 at 05:54:35PM +0800, Ross Moore wrote: > Hi, > Any update on this before I wipe the disks and start again? Hi Ross, Sorry but I failed to reproduce it locally, although I've tried various disk operations like balance, dev add/del etc... So have you also tried the latest btrf

Re: BTRFS Bug

Ross Moore rossmoore.net> writes: [...] > >> It reports Total as smaller than Used. That just seems very > >> wrong to me. I'd also like to rescue my filesystem rather than kill it > >> and restore from backup if possible (since it's pretty big and > >> restoring would take a while / be error-pro

Re: BTRFS Bug

That's a big file - is that a dump of all the metadata? It's around 800MB. Two files provided, one with the errors/warnings, one the actual output. Time-limited link to download, can you let me know when you have downloaded a copy please? http://akiajwevbuo5lh2yiu7q.sharing.s3.amazonaws.com/btrfs-

Re: BTRFS Bug

On Mon, Nov 12, 2012 at 10:37:58PM +0800, Ross Moore wrote: > Hi, > > I have a BTRFS filesystem that seems to be suffering from a few > problems. I'll post the first one, which looks most bizarre to me. > > The filesystem is mounted at /media/Media. It consists of 4 devices in > RAID1 (both metad

BTRFS Bug

Hi, I have a BTRFS filesystem that seems to be suffering from a few problems. I'll post the first one, which looks most bizarre to me. The filesystem is mounted at /media/Media. It consists of 4 devices in RAID1 (both metadata and data), of sizes 3*2TB and 1*1TB. The result of sudo btrfs fi df /m

Re: btrfs bug

On Tue, Jan 31, 2012 at 11:20 PM, Thomas Weber wrote: > Hello Mitch, > > I have good news for you. I looked through all log files and found in the > everything.log the following: > > Regards, > Thomas > > > Jan 31 05:12:24 localhost kernel: [87276.968049] btrfs memmove bogus > src_offset 1870 move

Re: btrfs bug

Hello Mitch, I have good news for you. I looked through all log files and found in the everything.log the following: Regards, Thomas Jan 31 05:12:24 localhost kernel: [87276.968049] btrfs memmove bogus src_offset 1870 move len 687876531 len 4096 Jan 31 05:12:24 localhost kernel: [87276.9681

Re: btrfs bug

Hello Mitch, On 01/31/2012 10:37 PM, Mitch Harder wrote: On Tue, Jan 31, 2012 at 12:04 PM, Thomas Weber wrote: Hello, this morning my laptop with btrfs crashed. It is an ssd drive. It is a Linux aramis 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:40:20 CET 2012 x86_64 Intel(R) Core(TM)2 Duo CP

Re: btrfs bug

On Tue, Jan 31, 2012 at 12:04 PM, Thomas Weber wrote: > Hello, > > this morning my laptop with btrfs crashed. It is an ssd drive. > > It is a Linux aramis 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:40:20 CET > 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel > GNU/Linux > > Regar

btrfs bug

Hello, this morning my laptop with btrfs crashed. It is an ssd drive. It is a Linux aramis 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:40:20 CET 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel GNU/Linux Regards, Thomas This two lines are from a photo, that i made. > kerne

Re: Btrfs bug with g38867a2 and a question

On Fri, Sep 23, 2011 at 11:34:40AM -0400, Josef Bacik wrote: > Yeah this is a different problem that's fixed upstream, so reboot into > your other newer kernel with -o clear_cache. Thanks, Ok I'm back in business now, thanks... Now I'll try to understand why my pc sometimes hangs doing write IOs

Re: Btrfs bug with g38867a2 and a question

On 09/23/2011 11:31 AM, Mathieu Chouquet-Stringer wrote: > On Fri, Sep 23, 2011 at 10:49:22AM -0400, Josef Bacik wrote: >> Ok I have no idea how this could happen. Can you mount -o clear_cache >> and see if it's just the cache that's bad? Thanks, > > Did that and got this (it's a never ending st

Re: Btrfs bug with g38867a2 and a question

On Fri, Sep 23, 2011 at 10:49:22AM -0400, Josef Bacik wrote: > Ok I have no idea how this could happen. Can you mount -o clear_cache > and see if it's just the cache that's bad? Thanks, Did that and got this (it's a never ending story, this is from a F16 alpha boot cd hence stack trace could be

Re: Btrfs bug with g38867a2 and a question

On 09/23/2011 08:55 AM, Mathieu Chouquet-Stringer wrote: > On Thu, Sep 22, 2011 at 10:32:13PM +0200, Mathieu Chouquet-Stringer wrote: >> On Thu, Sep 22, 2011 at 09:30:07PM +0200, Mathieu Chouquet-Stringer wrote: >>> On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote: Oh wow sorry I se

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 10:32:13PM +0200, Mathieu Chouquet-Stringer wrote: > On Thu, Sep 22, 2011 at 09:30:07PM +0200, Mathieu Chouquet-Stringer wrote: > > On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote: > > > Oh wow sorry I sent you the completely wrong patch, I wish I had caught > >

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 09:30:07PM +0200, Mathieu Chouquet-Stringer wrote: > On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote: > > Oh wow sorry I sent you the completely wrong patch, I wish I had caught > > your reply earlier. Can you run with this patch, which is the one I > > meant to

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 03:00:03PM -0400, Josef Bacik wrote: > Oh wow sorry I sent you the completely wrong patch, I wish I had caught > your reply earlier. Can you run with this patch, which is the one I > meant to give you :). Thanks, No worries, I've applied your patch (seems your thunderbird

Re: Btrfs bug with g38867a2 and a question

On 09/22/2011 02:22 PM, Mathieu Chouquet-Stringer wrote: > On Thu, Sep 22, 2011 at 10:12:12AM -0400, Josef Bacik wrote: >> Well that is from the tree logging code, so give this a whirl. It's >> going to dump a lot of info so make sure you capture everything before >> the --- cut here --- line. Th

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 10:12:12AM -0400, Josef Bacik wrote: > Well that is from the tree logging code, so give this a whirl. It's > going to dump a lot of info so make sure you capture everything before > the --- cut here --- line. Thanks, Here's the output of this patch: http://mathieu.csetco

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 10:12:12AM -0400, Josef Bacik wrote: > Well that is from the tree logging code, so give this a whirl. It's > going to dump a lot of info so make sure you capture everything before > the --- cut here --- line. Thanks, The patch doesn't apply cleanly to the latest git (sinc

Re: Btrfs bug with g38867a2 and a question

On 09/22/2011 02:05 AM, Mathieu Chouquet-Stringer wrote: > > On Sep 22, 2011 1:11 AM, "David Sterba" > wrote: >> >> On Wed, Sep 21, 2011 at 04:18:29PM -0400, Josef Bacik wrote: >> > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c >> > index b128fa0..66ba0a7 100644 >> > ---

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 01:05:28PM +0200, David Sterba wrote: > On Thu, Sep 22, 2011 at 12:13:44PM +0200, Mathieu Chouquet-Stringer wrote: > > On Thu, Sep 22, 2011 at 01:10:55AM +0200, David Sterba wrote: > > > please prefix printk messages with "btrfs: " > > > > Well my computer crashed before I

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 12:13:44PM +0200, Mathieu Chouquet-Stringer wrote: > On Thu, Sep 22, 2011 at 01:10:55AM +0200, David Sterba wrote: > > please prefix printk messages with "btrfs: " > > Well my computer crashed before I could reboot with the newly compiled > kernel. And now it bugs while it

Re: Btrfs bug with g38867a2 and a question

On Thu, Sep 22, 2011 at 01:10:55AM +0200, David Sterba wrote: > please prefix printk messages with "btrfs: " Well my computer crashed before I could reboot with the newly compiled kernel. And now it bugs while it tries to mount the kernel meaning my computer is fscked! :-) Bug at fs/btrfs/free-s

Re: Btrfs bug with g38867a2 and a question

On Wed, Sep 21, 2011 at 04:18:29PM -0400, Josef Bacik wrote: > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index b128fa0..66ba0a7 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -782,7 +782,12 @@ static noinline int cow_file_range(struct inode *inode, > struct extent_map_

Re: Btrfs bug with g38867a2 and a question

On Wed, Sep 21, 2011 at 04:18:29PM -0400, Josef Bacik wrote: > Yup, can you apply this patch and reproduce? It will print out some > debug info before the --- cut here --- line, which is what I need. Thanks, Compiling right now. That said, I had the same exact trace under rc6-00067-gf1fcd9f (ri

Re: Btrfs bug with g38867a2 and a question

On 09/21/2011 02:53 PM, Mathieu Chouquet-Stringer wrote: > Hello all, > > I've been using BTRFS for quite some time on this laptop and I just > recompiled the latest kernel from git (3.1.0-rc6-00247-g38867a2). After > a couple minutes, I hit this bug twice (this a hand written transcript, >

Btrfs bug with g38867a2 and a question

Hello all, I've been using BTRFS for quite some time on this laptop and I just recompiled the latest kernel from git (3.1.0-rc6-00247-g38867a2). After a couple minutes, I hit this bug twice (this a hand written transcript, pics here [1]) kernel BUG at fs/btrfs/inode.c:785! stack being:

btrfs bug

Hi All I've been using btrfs for some time already however recently the filesystem got corrupted somehow. Currently when I try to mount the filesystem the following error message is displayed and after few seconds system freezes completely: [ 250.620511] [ cut here ] [ 2

Re: btrfs bug in 2.6.37

On Di 1.Feb'11 at 16:25:11 -0600, cwillu wrote: > On Tue, Feb 1, 2011 at 3:51 PM, Carlos R. Mafra wrote: > > > > I am running 2.6.37 plus the revert of bf9dc102e284 (which is related to > > drm). > > > > My /home is on btrfs as well as a 1TB external USB hard-disk. > > > > I was compiling 2.6.38

Re: btrfs bug in 2.6.37

On Tue, Feb 1, 2011 at 3:51 PM, Carlos R. Mafra wrote: > > I am running 2.6.37 plus the revert of bf9dc102e284 (which is related to drm). > > My /home is on btrfs as well as a 1TB external USB hard-disk. > > I was compiling 2.6.38-rc3 from /home/mafra/linux2.6 using > the external hd as the destin

btrfs bug in 2.6.37

I am running 2.6.37 plus the revert of bf9dc102e284 (which is related to drm). My /home is on btrfs as well as a 1TB external USB hard-disk. I was compiling 2.6.38-rc3 from /home/mafra/linux2.6 using the external hd as the destination of the compiled files: make -j4 O=/mnt/wd/kernel-compile So

btrfs BUG during Ceph cosd truncate() syscall

Hi, I got this kernel BUG on a server running multiple Ceph cosd instances. I'm not sure what was going on at the time, as I just noticed this on my serial console for this node. It looks like another example of the truncate issue in Matt Weil's report. Please let me know what other information

Re: btrfs BUG during Ceph cosd open() syscall

The btrfs_orphan_commit_root warning is also reproducable in our ceph environment. Regards Christian 2011/1/26 Matt Weil : > heavy writes as well > > Jan  5 16:56:46 linuscs101 kernel: [ 3666.496742] [ cut here > ] >> >>  Jan  5 16:56:46 linuscs101 kernel: [ 3666.496754] W

Re: btrfs BUG during Ceph cosd open() syscall

heavy writes as well Jan 5 16:56:46 linuscs101 kernel: [ 3666.496742] [ cut here ] Jan 5 16:56:46 linuscs101 kernel: [ 3666.496754] WARNING: at fs/btrfs/inode.c:2143 btrfs_orphan_commit_root+0xb0/0xc0() Jan 5 16:56:46 linuscs101 kernel: [ 3666.496756] Hardware name

Re: btrfs BUG during Ceph cosd open() syscall

Hi, On Wed, 2011-01-26 at 10:59 -0700, Jim Schutt wrote: > Hi, > > I got this kernel BUG on a server running multiple Ceph > cosd instances, during a heavy write load generated by > multiple Ceph clients. > > The server was running the current ceph unstable kernel > (a3f5274e535 in > git://git

btrfs BUG during Ceph cosd open() syscall

Hi, I got this kernel BUG on a server running multiple Ceph cosd instances, during a heavy write load generated by multiple Ceph clients. The server was running the current ceph unstable kernel (a3f5274e535 in git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git). Please let me k

Re: tiny btrfs bug.....

Hi, > In stead, df reports the size of the partition to be about > 60GB. For each GB written to the partition, 2GB gets used. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- Chris Ball One Laptop Per Child -- To unsubscribe fro

tiny btrfs bug.....

Hi there. I'm running my root on a raid1 btrfs partition stretching over two partitions on two separate disks. Each partition is 30GB, so I would expect the raid to be 30GB big, being a mirror and all. In stead, df reports the size of the partition to be about 60GB. For each GB written to the pa

Re: btrfs Bug?

7;t doing this that wasn't the cause. -chris > > > -- Original Message -- > From: Chris Mason > To: Justin > Cc: linux-btrfs@vger.kernel.org > Subject: Re: btrfs Bug? > Date: Fri, 9 Apr 2010 07:18:44 -0400 > > On Thu, Apr 08, 2010 at 06:

Re: btrfs Bug?

As far as I know TRIM was enabled. I didn't forcibly disable it and I'm under the assumption that btrfs enables it when an SSD is detected. -- Original Message -- From: Chris Mason To: Justin Cc: linux-btrfs@vger.kernel.org Subject: Re: btrfs Bug? Date: Fri, 9 Apr

Re: btrfs Bug?

On Thu, Apr 08, 2010 at 06:46:40PM +, Justin wrote: > Unfortunately I did reformat. > Actually, I did a complete zero-out of the drive with dd, and then I ran > "badblocks -w" on the drive, which returned 0 bad blocks (not sure if this is > really a good test for SSD's as there's some amount

Re: btrfs Bug?

Unfortunately I did reformat. Actually, I did a complete zero-out of the drive with dd, and then I ran "badblocks -w" on the drive, which returned 0 bad blocks (not sure if this is really a good test for SSD's as there's some amount of internal voo-doo on the drive itself). For future reference

Re: btrfs Bug?

On Tue, Apr 06, 2010 at 05:08:12PM +, yoost...@netzero.com wrote: > Background: > Was checking E-mail and browsing the internet when suddenly Pidgin crashed > out. I thought that was pretty weird so I went to go re-start Pidgin when I > noticed the machine hang really hard for about 30 second

Re: btrfs Bug?

After reading around a bit on the btrfs wiki (the Getting_Started page and Gotchas page specifically) I found that I might be able to at least capture an image of the drive in case any devs needed to take a look at it; unfortunately btrfs-image failed with the same error. I deduced that a repair

btrfs Bug?

Background: Was checking E-mail and browsing the internet when suddenly Pidgin crashed out. I thought that was pretty weird so I went to go re-start Pidgin when I noticed the machine hang really hard for about 30 seconds. The machine finally came back and that's when I noticed that my E-mail cli

Re: btrfs bug while defragmenting

On Wed, Mar 10, 2010 at 12:47:59PM -0800, Philip Love wrote: > I obtained a similar error doing a large write to an ext3 filesystem, so > there is another problem somewhere. Sorry for the inconvenience. > Phil-- I was going to ask about memory corruptions because I couldn't trigger this bug. But

Re: btrfs bug while defragmenting

I obtained a similar error doing a large write to an ext3 filesystem, so there is another problem somewhere. Sorry for the inconvenience. Phil-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: btrfs bug while defragmenting

> I reproduced it again. The fs is idle apart from the defragment. > > mount -o nodatacow /dev/sdc1 backend > btrfsctl -d /mnt/backend/phil/i2 > This time I just mounted normally, please let me know what additional debug info you need. Thanks Phil mount /dev/sdc1 /mnt/backend btrfsctl -d /mnt

Re: btrfs bug while defragmenting

Also the 'file data blocks allocated' in the btrfsck looks wrong. sentryA:~ # btrfsck /dev/sdc1 found 95418703872 bytes used err is 0 total csum bytes: 92762192 total tree bytes: 430219264 total fs tree bytes: 186494976 btree space waste bytes: 72747390 file data blocks allocated: 193564269821952

Re: btrfs bug while defragmenting

> Well, I don't think that count is quite right. But I also don't see > anything in the ioctl that could cause it. How easily can you reproduce > this? > > I do see that the ioctl should be triple checking the page is part of > the mapping after doing a readpage on it, but it should only get dr

Re: btrfs bug while defragmenting

On Tue, Mar 09, 2010 at 10:45:13AM -0800, Philip Love wrote: > I had some 10gb files that I was using for random write testing (with cow > enabled). I remount the fs with nodatacow, then ran btrfsctl to defragement > the file. A BUG message appeared in the messages file. After a reboot btrfsck >

btrfs bug while defragmenting

I had some 10gb files that I was using for random write testing (with cow enabled). I remount the fs with nodatacow, then ran btrfsctl to defragement the file. A BUG message appeared in the messages file. After a reboot btrfsck gave no errors. Please let me know what extra information you need.

Re: btrfs BUG on creating huge sparse file

> > PagePrivate is very common. try_to_releasepage failing on a clean page > > > > without the writeback bit set and without dirty/locked buffers will be > > > > pretty rare. > > > > > > Yup. btrfs seems to tag most(if not all) dirty pages with PG_

  1   2   >