Re: [GIT PULL] Btrfs fixes for 4.17-rc6

[Linus Torvalds]

On Sun, May 20, 2018 at 8:21 AM David Sterba  wrote:

> They IMHO qualify for a late rc, though I did not expect that many.

Especially with the tree-log.c changes being fairly big, I took a look, and
I have to say that I appreciate (a) the warning in the pull request and (b)
the extensive log messages explaining the problems these patches fix.

I obviously still prefer to see only small and simple one-liners just
before I'm making ready to release rc6, but in the absence of oneliners I
do appreciate good explanations.

Thanks,

   Linus
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.15-rc2

[David Sterba]

On Wed, Nov 29, 2017 at 02:31:24PM -0800, Linus Torvalds wrote:
> On Wed, Nov 29, 2017 at 11:28 AM, David Sterba  wrote:
> >
> > With signed tag: for-4.15-rc2-tag
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc2
> 
> Oh, please actually ask me to pull the signed tag (exact same
> pull-request, just point git request-pull at the tag),

Will do next time.

> because now
> what happened was that first I just pulled that branch you mentioned,
> and only noticed that "With signed tag:" notice after I had already
> pulled and was filling in the merge message.
> 
> Anyway, I redid the pull with the proper signed tag, but it was just
> annoying extra work.
> 
> And I wonder how many times I _hadn't_ noticed that, because I didn't
> have your key in my keyring either. Or maybe I caught it the first
> time.

All my previous pull requests were like that. I did the split branch/tag
beacuse the ambiguous name for branch and brings some hassle to push or
remove them. I thought a separate tag with same top commit as the branch
plus mentioning the tag in the mail would be enough to verify the pulled
branch. But apparently was not, sorry for the trouble. 
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.15-rc2

[Linus Torvalds]

On Wed, Nov 29, 2017 at 11:28 AM, David Sterba  wrote:
>
> With signed tag: for-4.15-rc2-tag
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc2

Oh, please actually ask me to pull the signed tag (exact same
pull-request, just point git request-pull at the tag), because now
what happened was that first I just pulled that branch you mentioned,
and only noticed that "With signed tag:" notice after I had already
pulled and was filling in the merge message.

Anyway, I redid the pull with the proper signed tag, but it was just
annoying extra work.

And I wonder how many times I _hadn't_ noticed that, because I didn't
have your key in my keyring either. Or maybe I caught it the first
time.

Linus
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.14-rc4

[Liu Bo]

On Fri, Oct 06, 2017 at 11:25:12PM +0100, Tomasz Kłoczko wrote:
> On rc3 is possible to observe warning about possible circular locking
> dependency which I've reported on btrfs list few days ago:
>

Thanks for the report, neither this nor the one you reported on rc2
looks like a deadlock to me.

- %mmap_sem is always 'current->mm->mmap_sem',
- fsync doesn't acquire %mmap_sem, does it?

Not sure why we have a dependency here, tend to be a false one.

thanks,
-liubo

> [  101.326724] ==
> [  101.326728] WARNING: possible circular locking dependency detected
> [  101.326734] 4.14.0-0.rc3.git1.1.fc28.x86_64 #1 Not tainted
> [  101.326738] --
> [  101.326743] mysqld/1253 is trying to acquire lock:
> [  101.326747]  (>mmap_sem){}, at: []
> get_user_pages_unlocked+0x5e/0x1b0
> [  101.326771]
> [  101.326775]  (>dio_sem){}, at: []
> btrfs_direct_IO+0x39f/0x400 [btrfs]
> [  101.326846]
> [  101.326851]
> [  101.326856]
> [  101.326875]__lock_acquire+0x1107/0x11d0
> [  101.326883]lock_acquire+0xa3/0x1f0
> [  101.326892]down_write+0x51/0xc0
> [  101.326949]btrfs_log_changed_extents+0x7e/0x6c0 [btrfs]
> [  101.327000]btrfs_log_inode+0x9c1/0x11d0 [btrfs]
> [  101.327049]btrfs_log_inode_parent+0x2df/0xad0 [btrfs]
> [  101.327096]btrfs_log_dentry_safe+0x60/0x80 [btrfs]
> [  101.327144]btrfs_sync_file+0x344/0x4f0 [btrfs]
> [  101.327155]vfs_fsync_range+0x4b/0xb0
> [  101.327162]do_fsync+0x3d/0x70
> [  101.327170]SyS_fsync+0x10/0x20
> [  101.327179]do_syscall_64+0x6c/0x1f0
> [  101.327185]return_from_SYSCALL_64+0x0/0x7a
> [  101.327188]
> [  101.327204]__lock_acquire+0x1107/0x11d0
> [  101.327212]lock_acquire+0xa3/0x1f0
> [  101.327219]__mutex_lock+0x7f/0xa40
> [  101.327226]mutex_lock_nested+0x1b/0x20
> [  101.327272]btrfs_log_inode+0x159/0x11d0 [btrfs]
> [  101.327317]btrfs_log_inode_parent+0x2df/0xad0 [btrfs]
> [  101.327360]btrfs_log_dentry_safe+0x60/0x80 [btrfs]
> [  101.327407]btrfs_sync_file+0x344/0x4f0 [btrfs]
> [  101.327415]vfs_fsync_range+0x4b/0xb0
> [  101.327422]do_fsync+0x3d/0x70
> [  101.327429]SyS_fsync+0x10/0x20
> [  101.327435]do_syscall_64+0x6c/0x1f0
> [  101.327441]return_from_SYSCALL_64+0x0/0x7a
> [  101.327444]
> [  101.327463]__sb_start_write+0x12b/0x1a0
> [  101.327508]start_transaction+0x368/0x4d0 [btrfs]
> [  101.327549]btrfs_join_transaction+0x1d/0x20 [btrfs]
> [  101.327589]delayed_ref_async_start+0x67/0xd0 [btrfs]
> [  101.327637]btrfs_worker_helper+0x93/0x610 [btrfs]
> [  101.327640]
> [  101.327656]__lock_acquire+0x1107/0x11d0
> [  101.327664]lock_acquire+0xa3/0x1f0
> [  101.327671]wait_for_completion+0x62/0x1d0
> [  101.327710]btrfs_async_run_delayed_refs+0x163/0x180 [btrfs]
> [  101.327752]__btrfs_end_transaction+0x1f2/0x2e0 [btrfs]
> [  101.327790]btrfs_end_transaction+0x10/0x20 [btrfs]
> [  101.327832]btrfs_dirty_inode+0x71/0xd0 [btrfs]
> [  101.327871]btrfs_update_time+0x81/0xc0 [btrfs]
> [  101.327877]touch_atime+0xab/0xd0
> [  101.327920]btrfs_file_mmap+0x44/0x60 [btrfs]
> [  101.327927]mmap_region+0x3a3/0x5d0
> [  101.327932]do_mmap+0x2b6/0x410
> [  101.327938]vm_mmap_pgoff+0xcf/0x120
> [  101.327943]SyS_mmap_pgoff+0x1e1/0x280
> [  101.327949]SyS_mmap+0x1b/0x30
> [  101.327955]entry_SYSCALL_64_fastpath+0x1f/0xbe
> [  101.327958]
> [  101.327974]check_prev_add+0x351/0x700
> [  101.327981]__lock_acquire+0x1107/0x11d0
> [  101.327989]lock_acquire+0xa3/0x1f0
> [  101.327996]down_read+0x48/0xb0
> [  101.328003]get_user_pages_unlocked+0x5e/0x1b0
> [  101.328009]get_user_pages_fast+0x7a/0xc0
> [  101.328018]iov_iter_get_pages+0xc9/0x300
> [  101.328026]do_blockdev_direct_IO+0x192b/0x2940
> [  101.328034]__blockdev_direct_IO+0x2e/0x30
> [  101.328073]btrfs_direct_IO+0x171/0x400 [btrfs]
> [  101.328080]generic_file_direct_write+0xa3/0x160
> [  101.328123]btrfs_file_write_iter+0x2fb/0x610 [btrfs]
> [  101.328129]aio_write+0x116/0x1a0
> [  101.328134]do_io_submit+0x42d/0x940
> [  101.328139]SyS_io_submit+0x10/0x20
> [  101.328145]entry_SYSCALL_64_fastpath+0x1f/0xbe
> [  101.328149]
> [  101.328154] Chain exists of:
> [  101.328169]  Possible unsafe locking scenario:
> [  101.328174]CPU0CPU1
> [  101.328177]
> [  101.328180]   lock(>dio_sem);
> [  101.328187]lock(>log_mutex);
> [  101.328194]lock(>dio_sem);
> [  101.328200]   lock(>mmap_sem);
> [  101.328206]
> [  

Re: [GIT PULL] Btrfs fixes for 4.14-rc4

[Tomasz Kłoczko]

On rc3 is possible to observe warning about possible circular locking
dependency which I've reported on btrfs list few days ago:

[  101.326724] ==
[  101.326728] WARNING: possible circular locking dependency detected
[  101.326734] 4.14.0-0.rc3.git1.1.fc28.x86_64 #1 Not tainted
[  101.326738] --
[  101.326743] mysqld/1253 is trying to acquire lock:
[  101.326747]  (>mmap_sem){}, at: []
get_user_pages_unlocked+0x5e/0x1b0
[  101.326771]
[  101.326775]  (>dio_sem){}, at: []
btrfs_direct_IO+0x39f/0x400 [btrfs]
[  101.326846]
[  101.326851]
[  101.326856]
[  101.326875]__lock_acquire+0x1107/0x11d0
[  101.326883]lock_acquire+0xa3/0x1f0
[  101.326892]down_write+0x51/0xc0
[  101.326949]btrfs_log_changed_extents+0x7e/0x6c0 [btrfs]
[  101.327000]btrfs_log_inode+0x9c1/0x11d0 [btrfs]
[  101.327049]btrfs_log_inode_parent+0x2df/0xad0 [btrfs]
[  101.327096]btrfs_log_dentry_safe+0x60/0x80 [btrfs]
[  101.327144]btrfs_sync_file+0x344/0x4f0 [btrfs]
[  101.327155]vfs_fsync_range+0x4b/0xb0
[  101.327162]do_fsync+0x3d/0x70
[  101.327170]SyS_fsync+0x10/0x20
[  101.327179]do_syscall_64+0x6c/0x1f0
[  101.327185]return_from_SYSCALL_64+0x0/0x7a
[  101.327188]
[  101.327204]__lock_acquire+0x1107/0x11d0
[  101.327212]lock_acquire+0xa3/0x1f0
[  101.327219]__mutex_lock+0x7f/0xa40
[  101.327226]mutex_lock_nested+0x1b/0x20
[  101.327272]btrfs_log_inode+0x159/0x11d0 [btrfs]
[  101.327317]btrfs_log_inode_parent+0x2df/0xad0 [btrfs]
[  101.327360]btrfs_log_dentry_safe+0x60/0x80 [btrfs]
[  101.327407]btrfs_sync_file+0x344/0x4f0 [btrfs]
[  101.327415]vfs_fsync_range+0x4b/0xb0
[  101.327422]do_fsync+0x3d/0x70
[  101.327429]SyS_fsync+0x10/0x20
[  101.327435]do_syscall_64+0x6c/0x1f0
[  101.327441]return_from_SYSCALL_64+0x0/0x7a
[  101.327444]
[  101.327463]__sb_start_write+0x12b/0x1a0
[  101.327508]start_transaction+0x368/0x4d0 [btrfs]
[  101.327549]btrfs_join_transaction+0x1d/0x20 [btrfs]
[  101.327589]delayed_ref_async_start+0x67/0xd0 [btrfs]
[  101.327637]btrfs_worker_helper+0x93/0x610 [btrfs]
[  101.327640]
[  101.327656]__lock_acquire+0x1107/0x11d0
[  101.327664]lock_acquire+0xa3/0x1f0
[  101.327671]wait_for_completion+0x62/0x1d0
[  101.327710]btrfs_async_run_delayed_refs+0x163/0x180 [btrfs]
[  101.327752]__btrfs_end_transaction+0x1f2/0x2e0 [btrfs]
[  101.327790]btrfs_end_transaction+0x10/0x20 [btrfs]
[  101.327832]btrfs_dirty_inode+0x71/0xd0 [btrfs]
[  101.327871]btrfs_update_time+0x81/0xc0 [btrfs]
[  101.327877]touch_atime+0xab/0xd0
[  101.327920]btrfs_file_mmap+0x44/0x60 [btrfs]
[  101.327927]mmap_region+0x3a3/0x5d0
[  101.327932]do_mmap+0x2b6/0x410
[  101.327938]vm_mmap_pgoff+0xcf/0x120
[  101.327943]SyS_mmap_pgoff+0x1e1/0x280
[  101.327949]SyS_mmap+0x1b/0x30
[  101.327955]entry_SYSCALL_64_fastpath+0x1f/0xbe
[  101.327958]
[  101.327974]check_prev_add+0x351/0x700
[  101.327981]__lock_acquire+0x1107/0x11d0
[  101.327989]lock_acquire+0xa3/0x1f0
[  101.327996]down_read+0x48/0xb0
[  101.328003]get_user_pages_unlocked+0x5e/0x1b0
[  101.328009]get_user_pages_fast+0x7a/0xc0
[  101.328018]iov_iter_get_pages+0xc9/0x300
[  101.328026]do_blockdev_direct_IO+0x192b/0x2940
[  101.328034]__blockdev_direct_IO+0x2e/0x30
[  101.328073]btrfs_direct_IO+0x171/0x400 [btrfs]
[  101.328080]generic_file_direct_write+0xa3/0x160
[  101.328123]btrfs_file_write_iter+0x2fb/0x610 [btrfs]
[  101.328129]aio_write+0x116/0x1a0
[  101.328134]do_io_submit+0x42d/0x940
[  101.328139]SyS_io_submit+0x10/0x20
[  101.328145]entry_SYSCALL_64_fastpath+0x1f/0xbe
[  101.328149]
[  101.328154] Chain exists of:
[  101.328169]  Possible unsafe locking scenario:
[  101.328174]CPU0CPU1
[  101.328177]
[  101.328180]   lock(>dio_sem);
[  101.328187]lock(>log_mutex);
[  101.328194]lock(>dio_sem);
[  101.328200]   lock(>mmap_sem);
[  101.328206]
[  101.328213] 2 locks held by mysqld/1253:
[  101.328217]  #0:  (sb_writers#10){.+.+}, at: []
aio_write+0x191/0x1a0
[  101.328231]  #1:  (>dio_sem){}, at: []
btrfs_direct_IO+0x39f/0x400 [btrfs]
[  101.328277]
[  101.328285] CPU: 0 PID: 1253 Comm: mysqld Not tainted
4.14.0-0.rc3.git1.1.fc28.x86_64 #1
[  101.328290] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS
R2087H4 06/15/2012
[  101.328294] Call Trace:
[  101.328304]  dump_stack+0x8e/0xd6
[  101.328314]  print_circular_bug+0x1f6/0x2e0
[  101.328322]  ? 

Re: [GIT PULL] btrfs fixes and cleanups

[Qu Wenruo]

At 01/13/2017 12:10 AM, Liu Bo wrote:

Hi,

On Wed, Dec 28, 2016 at 05:30:59PM +0800, Qu Wenruo wrote:

Hi Liu,

At 12/15/2016 03:13 PM, Liu Bo wrote:

Hi David,

This is the collection of my patches targetting 4.10, I've
dropped patch "Btrfs: adjust len of writes if following a
preallocated extent" because of the deadlock caused by this
commit.

Patches are based on v4.9-rc8, and test against fstests with
default mount options has been taken to make sure it doesn't
break anything.

I haven't got a kernel.org git repo, so this is mainly for
tracking purpose and for testing git flow.

(cherry-pick patches might be the only way at this moment...sorry
for the inconvenience.)

Anyway, patches can be found at

https://github.com/liubogithub/btrfs-work.git for-dave

Thanks,
liubo

Liu Bo (9):
  Btrfs: add 'inode' for extent map tracepoint
  Btrfs: add truncated_len for ordered extent tracepoints
  Btrfs: use down_read_nested to make lockdep silent
  Btrfs: fix lockdep warning about log_mutex
  Btrfs: fix truncate down when no_holes feature is enabled
  Btrfs: fix btrfs_ordered_update_i_size to update disk_i_size properly
  Btrfs: fix comment in btrfs_page_mkwrite
  Btrfs: clean up btrfs_ordered_update_i_size


While testing David's for-next-20161219 branch, I found btrfs/06[0-5] will
cause the following kernel panic when ran them in a row.

[ 4207.963063] assertion failed: disk_i_size < i_size, file:
fs/btrfs//ordered-data.c, line: 1041
[ 4207.963722] [ cut here ]
[ 4207.964008] kernel BUG at fs/btrfs//ctree.h:3418!
[ 4207.964008] invalid opcode:  [#1] SMP
[ 4207.964008] Modules linked in: btrfs(O) netconsole ext4 jbd2 mbcache xor
zlib_deflate raid6_pq xfs [last unloaded: btrfs]
[ 4207.964008] CPU: 0 PID: 3829 Comm: kworker/u4:5 Tainted: G O4.9.0+
#60
[ 4207.964008] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.10.1-20161122_114906-anatol 04/01/2014
[ 4207.964008] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[ 4207.964008] task: 88000bbf8040 task.stack: c90006598000
[ 4207.964008] RIP: 0010:[]  []
assfail.constprop.10+0x1c/0x1e [btrfs]

[ 4207.964008] Call Trace:
[ 4207.964008]  [] btrfs_ordered_update_i_size+0x2b1/0x2e0
[btrfs]
[ 4207.964008]  [] btrfs_finish_ordered_io+0x335/0x6b0
[btrfs]
[ 4207.964008]  [] finish_ordered_fn+0x15/0x20 [btrfs]
[ 4207.964008]  [] btrfs_scrubparity_helper+0xef/0x610
[btrfs]
[ 4207.964008]  [] btrfs_endio_write_helper+0xe/0x10
[btrfs]
[ 4207.964008]  [] process_one_work+0x2af/0x720
[ 4207.964008]  [] ? process_one_work+0x22b/0x720
[ 4207.964008]  [] worker_thread+0x4b/0x4f0
[ 4207.964008]  [] ? process_one_work+0x720/0x720
[ 4207.964008]  [] ? process_one_work+0x720/0x720
[ 4207.964008]  [] kthread+0xf3/0x110
[ 4207.964008]  [] ? kthread_park+0x60/0x60
[ 4207.964008]  [] ret_from_fork+0x27/0x40
[ 4207.964008] Code: c7 00 e4 46 a0 48 89 e5 e8 c8 3c d8 e0 0f 0b 55 89 f1
48 c7 c2 83 90 46 a0 48 89 fe 48 c7 c7 b0 e4 46 a0 48 89 e5 e8 aa 3c d8 e0
<0f> 0b 55 89 f1 48 c7 c2 fb 90 46 a0 48 89 fe 48 c7 c7 e8 e5 46
[ 4207.964008] RIP  [] assfail.constprop.10+0x1c/0x1e
[btrfs]
[ 4207.964008]  RSP 
[ 4207.964008] ---[ end trace f7759d2fce14da9f ]---

Not sure if it's related to patch or just it exposed some bug we don't find
before.

Hopes it will help.



Thanks for spotting it, just found out that this ASSERT is not true any
more after patch "Btrfs: fix btrfs_ordered_update_i_size to update
disk_i_size properly".

I'm doing a v2 to remove it.


Glad it's not a big problem.

Thanks,
Qu



Thanks,

-liubo


Thanks,
Qu


  Btrfs: fix another race between truncate and lockless dio write

 fs/btrfs/extent-tree.c   |  3 ++-
 fs/btrfs/inode.c | 43 +++
 fs/btrfs/ordered-data.c  | 42 --
 fs/btrfs/tree-log.c  | 13 ++---
 include/trace/events/btrfs.h | 16 
 5 files changed, 83 insertions(+), 34 deletions(-)










--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] btrfs fixes and cleanups

[Liu Bo]

Hi,

On Wed, Dec 28, 2016 at 05:30:59PM +0800, Qu Wenruo wrote:
> Hi Liu,
> 
> At 12/15/2016 03:13 PM, Liu Bo wrote:
> > Hi David,
> > 
> > This is the collection of my patches targetting 4.10, I've
> > dropped patch "Btrfs: adjust len of writes if following a
> > preallocated extent" because of the deadlock caused by this
> > commit.
> > 
> > Patches are based on v4.9-rc8, and test against fstests with
> > default mount options has been taken to make sure it doesn't
> > break anything.
> > 
> > I haven't got a kernel.org git repo, so this is mainly for
> > tracking purpose and for testing git flow.
> > 
> > (cherry-pick patches might be the only way at this moment...sorry
> > for the inconvenience.)
> > 
> > Anyway, patches can be found at
> > 
> > https://github.com/liubogithub/btrfs-work.git for-dave
> > 
> > Thanks,
> > liubo
> > 
> > Liu Bo (9):
> >   Btrfs: add 'inode' for extent map tracepoint
> >   Btrfs: add truncated_len for ordered extent tracepoints
> >   Btrfs: use down_read_nested to make lockdep silent
> >   Btrfs: fix lockdep warning about log_mutex
> >   Btrfs: fix truncate down when no_holes feature is enabled
> >   Btrfs: fix btrfs_ordered_update_i_size to update disk_i_size properly
> >   Btrfs: fix comment in btrfs_page_mkwrite
> >   Btrfs: clean up btrfs_ordered_update_i_size
> 
> While testing David's for-next-20161219 branch, I found btrfs/06[0-5] will
> cause the following kernel panic when ran them in a row.
> 
> [ 4207.963063] assertion failed: disk_i_size < i_size, file:
> fs/btrfs//ordered-data.c, line: 1041
> [ 4207.963722] [ cut here ]
> [ 4207.964008] kernel BUG at fs/btrfs//ctree.h:3418!
> [ 4207.964008] invalid opcode:  [#1] SMP
> [ 4207.964008] Modules linked in: btrfs(O) netconsole ext4 jbd2 mbcache xor
> zlib_deflate raid6_pq xfs [last unloaded: btrfs]
> [ 4207.964008] CPU: 0 PID: 3829 Comm: kworker/u4:5 Tainted: G O4.9.0+
> #60
> [ 4207.964008] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> 1.10.1-20161122_114906-anatol 04/01/2014
> [ 4207.964008] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
> [ 4207.964008] task: 88000bbf8040 task.stack: c90006598000
> [ 4207.964008] RIP: 0010:[]  []
> assfail.constprop.10+0x1c/0x1e [btrfs]
> 
> [ 4207.964008] Call Trace:
> [ 4207.964008]  [] btrfs_ordered_update_i_size+0x2b1/0x2e0
> [btrfs]
> [ 4207.964008]  [] btrfs_finish_ordered_io+0x335/0x6b0
> [btrfs]
> [ 4207.964008]  [] finish_ordered_fn+0x15/0x20 [btrfs]
> [ 4207.964008]  [] btrfs_scrubparity_helper+0xef/0x610
> [btrfs]
> [ 4207.964008]  [] btrfs_endio_write_helper+0xe/0x10
> [btrfs]
> [ 4207.964008]  [] process_one_work+0x2af/0x720
> [ 4207.964008]  [] ? process_one_work+0x22b/0x720
> [ 4207.964008]  [] worker_thread+0x4b/0x4f0
> [ 4207.964008]  [] ? process_one_work+0x720/0x720
> [ 4207.964008]  [] ? process_one_work+0x720/0x720
> [ 4207.964008]  [] kthread+0xf3/0x110
> [ 4207.964008]  [] ? kthread_park+0x60/0x60
> [ 4207.964008]  [] ret_from_fork+0x27/0x40
> [ 4207.964008] Code: c7 00 e4 46 a0 48 89 e5 e8 c8 3c d8 e0 0f 0b 55 89 f1
> 48 c7 c2 83 90 46 a0 48 89 fe 48 c7 c7 b0 e4 46 a0 48 89 e5 e8 aa 3c d8 e0
> <0f> 0b 55 89 f1 48 c7 c2 fb 90 46 a0 48 89 fe 48 c7 c7 e8 e5 46
> [ 4207.964008] RIP  [] assfail.constprop.10+0x1c/0x1e
> [btrfs]
> [ 4207.964008]  RSP 
> [ 4207.964008] ---[ end trace f7759d2fce14da9f ]---
> 
> Not sure if it's related to patch or just it exposed some bug we don't find
> before.
> 
> Hopes it will help.
>

Thanks for spotting it, just found out that this ASSERT is not true any
more after patch "Btrfs: fix btrfs_ordered_update_i_size to update
disk_i_size properly".

I'm doing a v2 to remove it.

Thanks,

-liubo
 
> Thanks,
> Qu
> 
> >   Btrfs: fix another race between truncate and lockless dio write
> > 
> >  fs/btrfs/extent-tree.c   |  3 ++-
> >  fs/btrfs/inode.c | 43 
> > +++
> >  fs/btrfs/ordered-data.c  | 42 
> > --
> >  fs/btrfs/tree-log.c  | 13 ++---
> >  include/trace/events/btrfs.h | 16 
> >  5 files changed, 83 insertions(+), 34 deletions(-)
> > 
> 
> 
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] btrfs fixes and cleanups

[Qu Wenruo]

Hi Liu,

At 12/15/2016 03:13 PM, Liu Bo wrote:

Hi David,

This is the collection of my patches targetting 4.10, I've
dropped patch "Btrfs: adjust len of writes if following a
preallocated extent" because of the deadlock caused by this
commit.

Patches are based on v4.9-rc8, and test against fstests with
default mount options has been taken to make sure it doesn't
break anything.

I haven't got a kernel.org git repo, so this is mainly for
tracking purpose and for testing git flow.

(cherry-pick patches might be the only way at this moment...sorry
for the inconvenience.)

Anyway, patches can be found at

https://github.com/liubogithub/btrfs-work.git for-dave

Thanks,
liubo

Liu Bo (9):
  Btrfs: add 'inode' for extent map tracepoint
  Btrfs: add truncated_len for ordered extent tracepoints
  Btrfs: use down_read_nested to make lockdep silent
  Btrfs: fix lockdep warning about log_mutex
  Btrfs: fix truncate down when no_holes feature is enabled
  Btrfs: fix btrfs_ordered_update_i_size to update disk_i_size properly
  Btrfs: fix comment in btrfs_page_mkwrite
  Btrfs: clean up btrfs_ordered_update_i_size


While testing David's for-next-20161219 branch, I found btrfs/06[0-5] 
will cause the following kernel panic when ran them in a row.


[ 4207.963063] assertion failed: disk_i_size < i_size, file: 
fs/btrfs//ordered-data.c, line: 1041

[ 4207.963722] [ cut here ]
[ 4207.964008] kernel BUG at fs/btrfs//ctree.h:3418!
[ 4207.964008] invalid opcode:  [#1] SMP
[ 4207.964008] Modules linked in: btrfs(O) netconsole ext4 jbd2 mbcache 
xor zlib_deflate raid6_pq xfs [last unloaded: btrfs]
[ 4207.964008] CPU: 0 PID: 3829 Comm: kworker/u4:5 Tainted: G 
O4.9.0+ #60
[ 4207.964008] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.10.1-20161122_114906-anatol 04/01/2014

[ 4207.964008] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[ 4207.964008] task: 88000bbf8040 task.stack: c90006598000
[ 4207.964008] RIP: 0010:[]  [] 
assfail.constprop.10+0x1c/0x1e [btrfs]


[ 4207.964008] Call Trace:
[ 4207.964008]  [] 
btrfs_ordered_update_i_size+0x2b1/0x2e0 [btrfs]
[ 4207.964008]  [] btrfs_finish_ordered_io+0x335/0x6b0 
[btrfs]

[ 4207.964008]  [] finish_ordered_fn+0x15/0x20 [btrfs]
[ 4207.964008]  [] btrfs_scrubparity_helper+0xef/0x610 
[btrfs]
[ 4207.964008]  [] btrfs_endio_write_helper+0xe/0x10 
[btrfs]

[ 4207.964008]  [] process_one_work+0x2af/0x720
[ 4207.964008]  [] ? process_one_work+0x22b/0x720
[ 4207.964008]  [] worker_thread+0x4b/0x4f0
[ 4207.964008]  [] ? process_one_work+0x720/0x720
[ 4207.964008]  [] ? process_one_work+0x720/0x720
[ 4207.964008]  [] kthread+0xf3/0x110
[ 4207.964008]  [] ? kthread_park+0x60/0x60
[ 4207.964008]  [] ret_from_fork+0x27/0x40
[ 4207.964008] Code: c7 00 e4 46 a0 48 89 e5 e8 c8 3c d8 e0 0f 0b 55 89 
f1 48 c7 c2 83 90 46 a0 48 89 fe 48 c7 c7 b0 e4 46 a0 48 89 e5 e8 aa 3c 
d8 e0 <0f> 0b 55 89 f1 48 c7 c2 fb 90 46 a0 48 89 fe 48 c7 c7 e8 e5 46
[ 4207.964008] RIP  [] assfail.constprop.10+0x1c/0x1e 
[btrfs]

[ 4207.964008]  RSP 
[ 4207.964008] ---[ end trace f7759d2fce14da9f ]---

Not sure if it's related to patch or just it exposed some bug we don't 
find before.


Hopes it will help.

Thanks,
Qu


  Btrfs: fix another race between truncate and lockless dio write

 fs/btrfs/extent-tree.c   |  3 ++-
 fs/btrfs/inode.c | 43 +++
 fs/btrfs/ordered-data.c  | 42 --
 fs/btrfs/tree-log.c  | 13 ++---
 include/trace/events/btrfs.h | 16 
 5 files changed, 83 insertions(+), 34 deletions(-)




--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] btrfs fixes and cleanups

[David Sterba]

On Wed, Dec 14, 2016 at 11:13:32PM -0800, Liu Bo wrote:
> This is the collection of my patches targetting 4.10, I've
> dropped patch "Btrfs: adjust len of writes if following a
> preallocated extent" because of the deadlock caused by this
> commit.
> 
> Patches are based on v4.9-rc8, and test against fstests with
> default mount options has been taken to make sure it doesn't
> break anything.
> 
> I haven't got a kernel.org git repo, so this is mainly for
> tracking purpose and for testing git flow.
> 
> (cherry-pick patches might be the only way at this moment...sorry
> for the inconvenience.)
> 
> Anyway, patches can be found at
> 
>   https://github.com/liubogithub/btrfs-work.git for-dave

Thanks, I've added this branch to my list for-next source branches. Once
the merge window is closed, your branch will be part of the published
for-next.
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.8

[Chris Mason]

On 08/03/2016 06:31 AM, fdman...@kernel.org wrote:

From: Filipe Manana 

Hi Chris,

Please consider the following small set of fixes for the 4.8 kernel.
These are mostly send fixes, some of them reported and sent by Robbie Ko a
long time ago, which I reviewed, updated (specially the change logs) and
tested. All of these already have test cases in xfstests. The rest are
just some fsync related fixes and a cleanup. These have all been sent to
the mailing list before and were rebased against your 'next' branch.


Thanks Filipe!  Since these are all fixes, I'll queue up for rc2.  My 
second rc1 pull will go out today.


-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

[Chris Mason]

On Wed, Mar 02, 2016 at 09:24:46AM +0800, Qu Wenruo wrote:
> 
> 
> Chris Mason wrote on 2016/03/01 20:11 -0500:
> >On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
> >>
> >>
> >>Chris Mason wrote on 2016/03/01 11:06 -0500:
> >>>On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> Hi Chris,
> 
> On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> >The following changes since commit 
> >0fcb760afa6103419800674e22fb7f4de1f9670b:
> >
> >   Merge branch 'for-next' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into 
> > for-linus-4.6 (2016-02-24 10:21:44 -0800)
> >
> >are available in the git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> > integration-4.6
> >
> >for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> >
> >   Btrfs: do not collect ordered extents when logging that inode exists 
> > (2016-02-26 04:28:15 +)
> 
> Filipe's branch is based on some integration snapshot that contains the
> 'delete device by id' patchset that was removed from the 4.6 queue.
> 
> Your branch 'next' merges it back again through Filipe's tree, besides
> that the merge commits of the topic branches in my for-next appear
> twice. While the duplicated commits are only an esthetic issue, the
> extra branch bothers me.
> 
> I don't see a nice way how to avoid rebases in this cases. My suggestion
> is that Filipe rebases the branch on my for-chris that could have been
> an integration at some point.
> 
> As we're merging our branches that way for the first time I'd like to
> find the workflow also for the next dev cycles so I'm open to other
> suggestions.
> >>>
> >>>Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
> >>>branch.  The easiest way to avoid it in general is to only base trees on
> >>>top of things already in Linus' tree.  If there are specific
> >>>dependencies we can work it out on a case by case basis, but the merge
> >>>conflicts are almost always trivial.
> >>>
> >>>-chris
> >>
> >>Although off-topic, but do we need to rebase all sent pull to the new
> >>integration-4.6?
> >
> >Unless there are huge conflicts, it's actually much easier to base
> >against a recent v4.5-rcN.  That way if we do have to rebase the
> >integration branch, it doesn't mess up your pull request.
> >
> >If there are small conflicts, I can just deal with them when I pull.
> >For bigger conflicts, I'll either rebase on top of integration as
> >individual patches, or ask for help ;)
> 
> Thanks for the tip.
> Seems git can handle them well. (yeah, no more patch bombing )

Please keep patch bombing ;)  It's the best way to get things reviewed.
Besides, if people didn't like email, they would have found different
jobs long ago ;)

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

[Qu Wenruo]

Chris Mason wrote on 2016/03/01 20:11 -0500:

On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:



Chris Mason wrote on 2016/03/01 11:06 -0500:

On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:

Hi Chris,

On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:

The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:

   Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
(2016-02-24 10:21:44 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
integration-4.6

for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:

   Btrfs: do not collect ordered extents when logging that inode exists 
(2016-02-26 04:28:15 +)


Filipe's branch is based on some integration snapshot that contains the
'delete device by id' patchset that was removed from the 4.6 queue.

Your branch 'next' merges it back again through Filipe's tree, besides
that the merge commits of the topic branches in my for-next appear
twice. While the duplicated commits are only an esthetic issue, the
extra branch bothers me.

I don't see a nice way how to avoid rebases in this cases. My suggestion
is that Filipe rebases the branch on my for-chris that could have been
an integration at some point.

As we're merging our branches that way for the first time I'd like to
find the workflow also for the next dev cycles so I'm open to other
suggestions.


Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
branch.  The easiest way to avoid it in general is to only base trees on
top of things already in Linus' tree.  If there are specific
dependencies we can work it out on a case by case basis, but the merge
conflicts are almost always trivial.

-chris


Although off-topic, but do we need to rebase all sent pull to the new
integration-4.6?


Unless there are huge conflicts, it's actually much easier to base
against a recent v4.5-rcN.  That way if we do have to rebase the
integration branch, it doesn't mess up your pull request.

If there are small conflicts, I can just deal with them when I pull.
For bigger conflicts, I'll either rebase on top of integration as
individual patches, or ask for help ;)


Thanks for the tip.
Seems git can handle them well. (yeah, no more patch bombing )




Yes, I mean the in-band de-dup patchset. (If it is going to be merged)


For de-dup, I need to sit down and spend some more time reviewing it.  I
know it's taking a long time, but I want to make sure we get the disk
format right up front.  Lets target v4.7.


OK, I'll ensure no more modification to the existing patchset for easier 
review.


Although we will continue adding minor features like compression with 
dedup or ioctl improvement, so I'm afraid we'll continue bombing mail 
list with 20+ patches. :)


Thanks,
Qu


-chris





--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

[Chris Mason]

On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
> 
> 
> Chris Mason wrote on 2016/03/01 11:06 -0500:
> >On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> >>Hi Chris,
> >>
> >>On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> >>>The following changes since commit 
> >>>0fcb760afa6103419800674e22fb7f4de1f9670b:
> >>>
> >>>   Merge branch 'for-next' of 
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into 
> >>> for-linus-4.6 (2016-02-24 10:21:44 -0800)
> >>>
> >>>are available in the git repository at:
> >>>
> >>>   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> >>> integration-4.6
> >>>
> >>>for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> >>>
> >>>   Btrfs: do not collect ordered extents when logging that inode exists 
> >>> (2016-02-26 04:28:15 +)
> >>
> >>Filipe's branch is based on some integration snapshot that contains the
> >>'delete device by id' patchset that was removed from the 4.6 queue.
> >>
> >>Your branch 'next' merges it back again through Filipe's tree, besides
> >>that the merge commits of the topic branches in my for-next appear
> >>twice. While the duplicated commits are only an esthetic issue, the
> >>extra branch bothers me.
> >>
> >>I don't see a nice way how to avoid rebases in this cases. My suggestion
> >>is that Filipe rebases the branch on my for-chris that could have been
> >>an integration at some point.
> >>
> >>As we're merging our branches that way for the first time I'd like to
> >>find the workflow also for the next dev cycles so I'm open to other
> >>suggestions.
> >
> >Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
> >branch.  The easiest way to avoid it in general is to only base trees on
> >top of things already in Linus' tree.  If there are specific
> >dependencies we can work it out on a case by case basis, but the merge
> >conflicts are almost always trivial.
> >
> >-chris
> 
> Although off-topic, but do we need to rebase all sent pull to the new
> integration-4.6?

Unless there are huge conflicts, it's actually much easier to base
against a recent v4.5-rcN.  That way if we do have to rebase the
integration branch, it doesn't mess up your pull request.

If there are small conflicts, I can just deal with them when I pull.
For bigger conflicts, I'll either rebase on top of integration as
individual patches, or ask for help ;)

> Yes, I mean the in-band de-dup patchset. (If it is going to be merged)

For de-dup, I need to sit down and spend some more time reviewing it.  I
know it's taking a long time, but I want to make sure we get the disk
format right up front.  Lets target v4.7.

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

[Qu Wenruo]

Chris Mason wrote on 2016/03/01 11:06 -0500:

On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:

Hi Chris,

On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:

The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:

   Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
(2016-02-24 10:21:44 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
integration-4.6

for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:

   Btrfs: do not collect ordered extents when logging that inode exists 
(2016-02-26 04:28:15 +)


Filipe's branch is based on some integration snapshot that contains the
'delete device by id' patchset that was removed from the 4.6 queue.

Your branch 'next' merges it back again through Filipe's tree, besides
that the merge commits of the topic branches in my for-next appear
twice. While the duplicated commits are only an esthetic issue, the
extra branch bothers me.

I don't see a nice way how to avoid rebases in this cases. My suggestion
is that Filipe rebases the branch on my for-chris that could have been
an integration at some point.

As we're merging our branches that way for the first time I'd like to
find the workflow also for the next dev cycles so I'm open to other
suggestions.


Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
branch.  The easiest way to avoid it in general is to only base trees on
top of things already in Linus' tree.  If there are specific
dependencies we can work it out on a case by case basis, but the merge
conflicts are almost always trivial.

-chris


Although off-topic, but do we need to rebase all sent pull to the new 
integration-4.6?

Yes, I mean the in-band de-dup patchset. (If it is going to be merged)

Thanks,
Qu

--
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://vger.kernel.org/majordomo-info.html





--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

[Chris Mason]

On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> Hi Chris,
> 
> On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> > The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
> > 
> >   Merge branch 'for-next' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into 
> > for-linus-4.6 (2016-02-24 10:21:44 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> > integration-4.6
> > 
> > for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> > 
> >   Btrfs: do not collect ordered extents when logging that inode exists 
> > (2016-02-26 04:28:15 +)
> 
> Filipe's branch is based on some integration snapshot that contains the
> 'delete device by id' patchset that was removed from the 4.6 queue.
> 
> Your branch 'next' merges it back again through Filipe's tree, besides
> that the merge commits of the topic branches in my for-next appear
> twice. While the duplicated commits are only an esthetic issue, the
> extra branch bothers me.
> 
> I don't see a nice way how to avoid rebases in this cases. My suggestion
> is that Filipe rebases the branch on my for-chris that could have been
> an integration at some point.
> 
> As we're merging our branches that way for the first time I'd like to
> find the workflow also for the next dev cycles so I'm open to other
> suggestions.

Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
branch.  The easiest way to avoid it in general is to only base trees on
top of things already in Linus' tree.  If there are specific
dependencies we can work it out on a case by case basis, but the merge
conflicts are almost always trivial.

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

[David Sterba]

Hi Chris,

On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
> 
>   Merge branch 'for-next' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
> (2016-02-24 10:21:44 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> integration-4.6
> 
> for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> 
>   Btrfs: do not collect ordered extents when logging that inode exists 
> (2016-02-26 04:28:15 +)

Filipe's branch is based on some integration snapshot that contains the
'delete device by id' patchset that was removed from the 4.6 queue.

Your branch 'next' merges it back again through Filipe's tree, besides
that the merge commits of the topic branches in my for-next appear
twice. While the duplicated commits are only an esthetic issue, the
extra branch bothers me.

I don't see a nice way how to avoid rebases in this cases. My suggestion
is that Filipe rebases the branch on my for-chris that could have been
an integration at some point.

As we're merging our branches that way for the first time I'd like to
find the workflow also for the next dev cycles so I'm open to other
suggestions.
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.4

[Chris Mason]

On Thu, Dec 10, 2015 at 11:44:50AM +, fdman...@kernel.org wrote:
> From: Filipe Manana 
> 
> Hi Chris,
> 
> Please consider the following fixes for kernel 4.4. Two of them are fixes
> to new issues introduced in the 4.4 merge window and 4.4 release candidates.
> The other one just fixes a warning message that is confusing and has made
> several users wonder if they are supposed to do anything or not when we
> fail to read a space cache.
> All these fixes have been previously sent to the mailing list.

Thanks Filipe, I tested these and pushed out, along with my two from
this week.

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[Chris Mason]

On Thu, Nov 05, 2015 at 11:20:37AM +, fdman...@kernel.org wrote:
> From: Filipe Manana 
> 
> Hi Chris,
> 
> please consider the following fixes for the 4.4 merge window (they were
> all previously sent to the mailing list already).
> 
> One fixes a sleep inside atomic context issue, introduced by one patch
> in the integration-4.4 branch. Another two fix races regarding waiting
> for qgroup rescan worker to finish and a race between the qgroup rescan
> worker and unmounting the filesystem (leading to crashes). The remaining
> patch fixes an issue with partial direct IO writes, which has been
> introduced in the 4.0 kernel, and results either in an assertion failure
> (BUG_ON) when CONFIG_BTRFS_ASSERT=y or arithmetic underflow of an inode's
> outstanding extents counter (used for proper space reservation) when
> assertions are disabled.
> 
> Two test cases for fstests were sent recently to cover the issues regarding
> the races and the direct IO partial write regression.

Great, thanks Filipe.

I'll send these for my second pull (probably next Wed).

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for integration-4.3

[Chris Mason]

On Wed, Aug 19, 2015 at 07:37:42PM +0100, fdman...@kernel.org wrote:
 From: Filipe Manana fdman...@suse.com
 
 Hi Chris,
 
 Please consider the following fixes for your integration-4.3 branch.
 Nothing unusual. I included any Reviewed-by tags people added and a
 test case for xfstests for the file corruption after fsync fix.

Thanks Filipe, pulled.

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[Chris Mason]

On Tue, Jan 22, 2013 at 05:48:33PM -0700, Chris Mason wrote:
 Hi Linus,
 
 My for-linus branch has our batch of btrfs fixes:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
 
 We've been hammering away at a crc corruption as well, which I was
 really hoping to get into this pull.  It isn't nailed down yet, but we
 were finally able to get a solid way to reproduce.  The only good
 news is it isn't a recent regression.

Update on this, we've tracked down the crc errors and are doing final
checks on the patches.  Linus are you planning on taking this pull?  If
not I can just fold the new stuff into a bigger request.

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[Linus Torvalds]

On Thu, Jan 24, 2013 at 1:52 PM, Chris Mason chris.ma...@fusionio.com wrote:

 Update on this, we've tracked down the crc errors and are doing final
 checks on the patches.  Linus are you planning on taking this pull?  If
 not I can just fold the new stuff into a bigger request.

If you have them basically ready, add them to this, I haven't pulled
yet. So I'll just ignore this and wait for another pull request.

 Linus
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[Liu Bo]

On Tue, Jan 22, 2013 at 07:48:33PM -0500, Chris Mason wrote:
 Hi Linus,
 
 My for-linus branch has our batch of btrfs fixes:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
 
 We've been hammering away at a crc corruption as well, which I was
 really hoping to get into this pull.  It isn't nailed down yet, but we
 were finally able to get a solid way to reproduce.  The only good
 news is it isn't a recent regression.
 
 The most important batch of fixes in here come from Ilya.  They address
 a regression Liu Bo found in the balance ioctls for pausing and resuming
 a running balance across drives.
 
 Josef's orphan truncate patch fixes an obscure corruption we'd see
 during xfstests.
 
 Arne's patches address problems with subvolume quotas.  If the user
 destroys quota groups incorrectly the FS will refuse to mount.
 
 The rest are smaller fixes and plugs for memory leaks.

Hi,

Any chance to get these in this round?  I think they're good fixes,
a memory leak and a warning fix, both are got from xfstests.

- Btrfs: use right range to find checksum for compressed extents
  https://patchwork.kernel.org/patch/1937031/
- Btrfs: fix memory leak on extent map after fsync
  https://patchwork.kernel.org/patch/1946561/

thanks,
liubo

 
 Ilya Dryomov (6) commits (+94/-32):
 Btrfs: reorder locks and sanity checks in btrfs_ioctl_defrag (+9/-8)
 Btrfs: fix mutually exclusive op is running error code (+4/-4)
 Btrfs: fix a regression in balance usage filter (+8/-1)
 Btrfs: bring back balance pause/resume logic (+71/-17)
 Btrfs: fix unlock order in btrfs_ioctl_rm_dev (+1/-1)
 Btrfs: fix unlock order in btrfs_ioctl_resize (+1/-1)
 
 Liu Bo (4) commits (+18/-7):
 Btrfs: fix a bug when llseek for delalloc bytes behind prealloc extents 
 (+14/-6)
 Btrfs: let allocation start from the right raid type (+1/-1)
 Btrfs: reset path lock state to zero (+2/-0)
 Btrfs: fix off-by-one in lseek (+1/-0)
 
 Miao Xie (4) commits (+15/-7):
 Btrfs: fix missing write access release in btrfs_ioctl_resize() (+1/-0)
 Btrfs: do not delete a subvolume which is in a R/O subvolume (+5/-5)
 Btrfs: fix resize a readonly device (+4/-2)
 Btrfs: disable qgroup id 0 (+5/-0)
 
 Arne Jansen (2) commits (+19/-1):
 Btrfs: prevent qgroup destroy when there are still relations (+12/-1)
 Btrfs: ignore orphan qgroup relations (+7/-0)
 
 Josef Bacik (2) commits (+39/-16):
 Btrfs: add orphan before truncating pagecache (+38/-15)
 Btrfs: set flushing if we're limited flushing (+1/-1)
 
 Zach Brown (1) commits (+1/-0):
 btrfs: fix btrfs_cont_expand() freeing IS_ERR em
 
 Lukas Czerner (1) commits (+1/-1):
 btrfs: get the device in write mode when deleting it
 
 Eric Sandeen (1) commits (+14/-3):
 btrfs: update timestamps on truncate()
 
 Tsutomu Itoh (1) commits (+3/-1):
 Btrfs: fix memory leak in name_cache_insert()
 
 Total: (22) commits
 
  fs/btrfs/extent-tree.c |   6 ++-
  fs/btrfs/file.c|  10 ++--
  fs/btrfs/inode.c   |  82 +++
  fs/btrfs/ioctl.c   | 129 
 +++--
  fs/btrfs/qgroup.c  |  20 +++-
  fs/btrfs/send.c|   4 +-
  fs/btrfs/volumes.c |  21 ++--
  7 files changed, 204 insertions(+), 68 deletions(-)
 --
 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://vger.kernel.org/majordomo-info.html
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Liu Bo]

On 03/31/2012 01:51 AM, Chris Mason wrote:
 Hi everyone,
 
 This pull request is pretty big, picking up patches that have been under
 development for some time.  I have it in two branches:
 
 # against 3.3
 #
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
 
 # merged with linus git as of this morning (conflict in fs/btrfs/scrub.c)
 #
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
 for-linus-merged
 
 The conflict resolution was to pick my version of scrub.c and then go in
 and drop all the KM_ args from kmap/unmap_atomic.
 
 We've merged in the error handling patches from SuSE.  These are already
 shipping in the sles kernel, and they give btrfs the ability to abort
 transactions and go readonly on errors.  It involves a lot of churn as
 they clarify BUG_ONs, and remove the ones we now properly deal with.
 
 Josef reworked the way our metadata interacts with the page cache.
 page-private now points to the btrfs extent_buffer object, which makes
 everything faster.  He changed it so we write an whole extent buffer at
 a time instead of allowing individual pages to go down,, which will be
 important for the raid5/6 code (for the 3.5 merge window ;)
 
 Josef also made us more aggressive about dropping pages for metadata
 blocks that were freed due to COW.  Overall, our metadata caching is
 much faster now.
 
 We've integrated my patch for metadata bigger than the page size.  This
 allows metadata blocks up to 64KB in size.  In practice 16K and 32K seem
 to work best.  For workloads with lots of metadata, this cuts down the
 size of the extent allocation tree dramatically and fragments much less.
 

We still suffer pains in using a sectorsize larger than PAGE_SIZE, so
we'd better add a checker for it, something like:

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 20196f4..08e49d2 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2104,6 +2104,14 @@ int open_ctree(struct super_block *sb,
err = -EINVAL;
goto fail_alloc;
}
+   if (btrfs_super_sectorsize(disk_super)  PAGE_CACHE_SIZE) {
+   printk(KERN_ERR BTRFS: couldn't mount because sectorsize(%d)
+   was larger than PAGE_SIZE(%lu)\n,
+  btrfs_super_sectorsize(disk_super),
+  (unsigned long long)PAGE_CACHE_SIZE);
+   err = -EINVAL;
+   goto fail_alloc;
+   }

features = btrfs_super_incompat_flags(disk_super);
features |= BTRFS_FEATURE_INCOMPAT_MIXED_BACKREF;
-- 
1.6.5.2


thanks,
liubo

 Scrub was updated to support the larger block sizes, which ended up
 being a fairly large change (thanks Stefan Behrens).
 
 We also have an assortment of fixes and updates, especially to the
 balancing code (Ilya Dryomov), the back ref walker (Jan Schmidt) and the
 defragging code (Liu Bo).
 
 Jeff Mahoney (21) commits (+1982/-1051):
 btrfs: clean_tree_block should panic on observed memory corruption and 
 return void (+12/-7)
 btrfs: avoid NULL deref in btrfs_reserve_extent with DEBUG_ENOSPC (+2/-1)
 btrfs: Catch locking failures in {set,clear,convert}_extent_bit (+38/-20)
 btrfs: return void in functions without error conditions (+293/-410)
 btrfs: replace many BUG_ONs with proper error handling (+980/-385)
 btrfs: Remove set bits return from clear_extent_bit (+5/-7)
 btrfs: enhance transaction abort infrastructure (+300/-56)
 btrfs: Factor out tree-ops-merge_bio_hook call (+17/-5)
 btrfs: Fix kfree of member instead of structure (+3/-3)
 btrfs: btrfs_drop_snapshot should return int (+12/-8)
 btrfs: -submit_bio_hook error push-up (+31/-15)
 btrfs: find_and_setup_root error push-up (+6/-5)
 btrfs: __add_reloc_root error push-up (+16/-6)
 btrfs: btrfs_update_root error push-up (+7/-4)
 btrfs: Panic on bad rbtree operations (+39/-9)
 btrfs: Simplify btrfs_submit_bio_hook (+4/-3)
 btrfs: drop gfp_t from lock_extent (+63/-76)
 btrfs: add varargs to btrfs_error (+66/-9)
 btrfs: Simplify btrfs_insert_root (+3/-6)
 btrfs: split extent_state ops (+25/-15)
 btrfs: Add btrfs_panic() (+60/-1)
 
 Ilya Dryomov (11) commits (+177/-159):
 Btrfs: validate target profiles only if we are going to use them (+11/-16)
 Btrfs: stop silently switching single chunks to raid0 on balance (+2/-3)
 Btrfs: add wrappers for working with alloc profiles (+30/-30)
 Btrfs: move alloc_profile_is_valid() to volumes.c (+25/-30)
 Btrfs: make profile_is_valid() check more strict (+17/-12)
 Btrfs: fix infinite loop in btrfs_shrink_device() (+2/-3)
 Btrfs: improve the logic in btrfs_can_relocate() (+18/-6)
 Btrfs: allow dup for data chunks in mixed mode (+9/-4)
 Btrfs: add __get_block_group_index() helper (+12/-5)
 Btrfs: add get_restripe_target() helper (+50/-44)
 Btrfs: fix memory leak in resolver code (+1/-6)
 
 Mark Fasheh (10) commits (+60/-19):
 

Re: [GIT PULL] Btrfs fixes and features

[Linus Torvalds]

On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason chris.ma...@oracle.com wrote:

 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

This causes a new warning for me:

  fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
  fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
uninitialized in this function

Hmm?

Linus
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Linus Torvalds]

On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds
torva...@linux-foundation.org wrote:

 This causes a new warning for me:

  fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
  fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
 uninitialized in this function

 Hmm?

Ok, so presumably num_pages (which is num_extent_pages(eb-start,
eb-len)) cannot be zero, so I guess the code is ok. But gcc can't
know that, and it's an annoying warning.

So please fix, but it's not urgent. In the meantime I've pulled and pushed out.

Linus
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Chris Mason]

On Fri, Mar 30, 2012 at 12:50:26PM -0700, Linus Torvalds wrote:
 On Fri, Mar 30, 2012 at 10:51 AM, Chris Mason chris.ma...@oracle.com wrote:
 
  git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
  for-linus
 
 This causes a new warning for me:
 
   fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
   fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
 uninitialized in this function

Interesting that my gcc doesn't warn here.  Strictly speaking, gcc isn't
wrong, but num_extent_pages() will always be at least 1.  This function
is new in this pull, so it can't be a conflict.

Do you want a new pull with the ret = 0 patch?

int repair_eb_io_failure(struct btrfs_root *root, struct extent_buffer
*eb,
 int mirror_num)
{
struct btrfs_mapping_tree *map_tree = root-fs_info-mapping_tree;
u64 start = eb-start;
unsigned long i, num_pages = num_extent_pages(eb-start, eb-len);
int ret;

for (i = 0; i  num_pages; i++) {
struct page *p = extent_buffer_page(eb, i);
ret = repair_io_failure(map_tree, start, PAGE_CACHE_SIZE,
start, p, mirror_num);
if (ret)
break;
start += PAGE_CACHE_SIZE;
}

return ret;
}

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Chris Mason]

On Fri, Mar 30, 2012 at 12:54:03PM -0700, Linus Torvalds wrote:
 On Fri, Mar 30, 2012 at 12:50 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 
  This causes a new warning for me:
 
   fs/btrfs/extent_io.c: In function ‘repair_eb_io_failure’:
   fs/btrfs/extent_io.c:1940:6: warning: ‘ret’ may be used
  uninitialized in this function
 
  Hmm?
 
 Ok, so presumably num_pages (which is num_extent_pages(eb-start,
 eb-len)) cannot be zero, so I guess the code is ok. But gcc can't
 know that, and it's an annoying warning.

Whoops, my reply was too slow, sorry.  If you're curious my gcc that
doesn't warn in 4.6.3.

 
 So please fix, but it's not urgent. In the meantime I've pulled and pushed 
 out.

Ok, I'll send just the incremental in a later pull.

-chris
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes and features

[Alex]

Chris Mason chris.mason at oracle.com writes:

 
 Hi everyone,
 
 This pull request is pretty big, picking up patches that have been under
 development for some time.  I have it in two branches:
 

Thank you all guys for your time, effort and responses here.
No problems here so far ;-)




--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[Chris Mason]

On Fri, Dec 16, 2011 at 12:53:44PM -0500, Chris Mason wrote:
 Hi everyone,
 
 This pull request is bigger than I wanted it to be, but Josef has
 commits in here for some long running ENOSPC bugs in btrfs.  This is
 a few weeks of tracing our delalloc reservations from Josef, and then
 fixing up the related bugs.
 
 Outside of Josef's patches we have some assorted fixes.  Arne figured
 out we were orphaning whole snapshots if you unmounted enough times
 while the snapshot was being deleted.

Sorry, this part is missing:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

 
 Josef Bacik (6) commits (+212/-117):
 Btrfs: fix how we do delalloc reservations and how we free reservations 
 on error (+44/-13)
 Btrfs: fix num_workers_starting bug and other bugs in async thread 
 (+83/-78)
 Btrfs: only set cache_generation if we setup the block group (+1/-1)
 Btrfs: deal with enospc from dirtying inodes properly (+80/-22)
 Btrfs: don't panic if orphan item already exists (+1/-1)
 Btrfs: fix leaked space in truncate (+3/-2)
 
 Chris Mason (4) commits (+10/-4):
 Btrfs: fix btrfs_end_bio to deal with write errors to a single mirror 
 (+1/-1)
 Btrfs: deal with NULL srv_rsv in the delalloc inode reservation code 
 (+2/-2)
 Btrfs: add a cond_resched() into the worker loop (+1/-1)
 Btrfs: unplug every once and a while (+6/-0)
 
 Miao Xie (3) commits (+29/-13):
 Btrfs: fix wrong i_size when truncating a file to a larger size (+12/-6)
 Btrfs: fix inaccurate available space on raid0 profile (+13/-6)
 Btrfs: fix wrong disk space information of the files (+4/-1)
 
 Casey Schaufler (1) commits (+26/-5):
 BTRFS: Establish i_ops before calling d_instantiate
 
 Arne Jansen (1) commits (+32/-0):
 btrfs: keep orphans for subvolume deletion
 
 Li Zefan (1) commits (+2/-2):
 Btrfs: fix ctime update of on-disk inode
 
 Total: (16) commits (+309/-140)
 
  fs/btrfs/async-thread.c  |  117 ++
  fs/btrfs/async-thread.h  |4 +-
  fs/btrfs/ctree.h |3 +-
  fs/btrfs/delayed-inode.c |4 +-
  fs/btrfs/disk-io.c   |   34 ++
  fs/btrfs/extent-tree.c   |   45 
  fs/btrfs/file.c  |6 ++-
  fs/btrfs/inode.c |  180 
 +-
  fs/btrfs/ioctl.c |6 +-
  fs/btrfs/relocation.c|2 +
  fs/btrfs/scrub.c |8 ++-
  fs/btrfs/super.c |   32 +++--
  fs/btrfs/volumes.c   |8 ++-
  13 files changed, 309 insertions(+), 140 deletions(-)
 --
 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://vger.kernel.org/majordomo-info.html
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[nobody]

Chris Mason chris.mason at oracle.com writes:
 
 Hi everyone,
 
 This pull request is bigger than I wanted it to be, but Josef has
 commits in here for some long running ENOSPC bugs in btrfs. 

 % git log --no-merges --grep=enospc | grep commit | wc -l
45
 % git log --no-merges --grep=enospc|grep Date:
Date:   Fri Oct 7 11:55:34 2011 -0400
Date:   Mon Sep 26 17:12:22 2011 -0400
Date:   Tue Aug 30 10:19:10 2011 -0400
Date:   Mon Aug 29 14:06:00 2011 -0400
Date:   Tue Jul 26 17:00:46 2011 -0400
Date:   Fri Jul 15 15:16:44 2011 +
Date:   Tue Jun 7 16:07:44 2011 -0400
Date:   Tue Jun 7 15:07:51 2011 -0400
Date:   Fri May 27 16:11:38 2011 -0400
Date:   Wed May 25 13:10:16 2011 -0400
Date:   Tue Apr 5 11:57:27 2011 -0400
Date:   Wed Feb 16 13:57:04 2011 -0500
Date:   Wed Feb 16 13:10:41 2011 -0500
Date:   Fri Nov 12 23:17:56 2010 +
Date:   Wed May 26 11:31:00 2010 -0400
Date:   Tue May 25 20:56:50 2010 -0400
Date:   Fri Mar 19 14:38:13 2010 +
Date:   Thu Dec 17 15:47:17 2009 -0500
Date:   Wed Nov 11 10:16:57 2009 -0500
Date:   Tue Nov 10 21:23:48 2009 -0500
Date:   Tue Sep 22 14:48:44 2009 -0400
Date:   Mon Nov 17 21:12:00 2008 -0500
Date:   Fri Nov 7 18:17:11 2008 -0500
Date:   Fri Nov 7 09:06:11 2008 -0500
Date:   Wed Oct 29 14:49:05 2008 -0400
Date:   Thu Jan 3 09:22:38 2008 -0500
Date:   Mon Sep 17 11:00:51 2007 -0400
Date:   Wed Aug 29 09:11:44 2007 -0400


--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes

[Sage Weil]

Hi Chris-

This pull misses the clone reservation fix again... :)

http://www.spinics.net/lists/linux-btrfs/msg11826.html

Thanks!
sage



On Mon, 19 Sep 2011, Chris Mason wrote:

 Hi everyone,
 
 The for-linus branch of the btrfs tree on github:
 
 Head commit: a66e7cc626f42de6c745963fe0d807518fa49d39
 git://github.com/chrismason/linux.git for-linus
 
 Has the following fixes.  for-linus is against rc6, since some of these
 are regression fixes for earlier 3.1 btrfs commits.  The most important
 of the bunch is Josef's dentry fix, which avoids enoents if we race with
 multiple procs hitting on the same inode.  This bug is btrfs-specific,
 it came in with his optimization to cache the inode location during
 readdir.
 
 Li Zefan (3) commits (+9/-5):
 Btrfs: don't make a file partly checksummed through file clone (+5/-0)
 Btrfs: don't change inode flag of the dest clone file (+0/-1)
 Btrfs: fix pages truncation in btrfs_ioctl_clone() (+4/-4)
 
 Josef Bacik (1) commits (+11/-2):
 Btrfs: only clear the need lookup flag after the dentry is setup
 
 Jeff Liu (1) commits (+7/-2):
 BTRFS: Fix lseek return value for error
 
 Hidetoshi Seto (1) commits (+3/-2):
 btrfs: fix d_off in the first dirent
 
 Total: (6) commits (+30/-11)
 
  fs/btrfs/file.c  |9 +++--
  fs/btrfs/inode.c |   18 ++
  fs/btrfs/ioctl.c |   14 +-
  3 files changed, 30 insertions(+), 11 deletions(-)
 --
 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://vger.kernel.org/majordomo-info.html
 
 
--
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://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] btrfs fixes

[Tarkan Erimer]

On 07/08/2011 09:55 PM, Chris Mason wrote:

Hi everyone,

The for-linus branch of the btrfs-unstable repo:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus

Has three more fixes.  We're fixing oopsen during space balancing (btrfs
filesystem balance /mnt)) and during device removal.

Dave Sterba also sent in a patch to make /proc/mounts properly match a
few new mount options, which he (correctly I think) considers a
regression fix because it makes it hard for testers/users to verify the
options in a running config.



Hi Chris,

Maybe, any development regarding to the [BUG] Btrfs: Corrupted root 
filesystem subjected bug posted by me ?



Tarkan
--
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://vger.kernel.org/majordomo-info.html