Re: [PATCH] btrfs: add missing memset while reading compressed inline extents

On Fri, Apr 7, 2017 at 2:07 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 04/07/2017 12:07 AM, Filipe Manana wrote: >> >> On Wed, Mar 22, 2017 at 2:37 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> >>> >>

Re: [PATCH v3] fstests: btrfs: Check if btrfs will create inline-then-regular file extents

On Fri, Apr 7, 2017 at 1:28 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 04/07/2017 12:02 AM, Filipe Manana wrote: >> >> On Thu, Apr 6, 2017 at 2:28 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: >>> >>> Btrfs allows inline file extent

Re: [PATCH] fstests: btrfs: Check if btrfs will create inline-then-regular file extents

On Wed, Apr 5, 2017 at 3:14 AM, Qu Wenruo wrote: > Btrfs allows inline file extent if and only if > 1) It's at offset 0 > 2) It's smaller than min(max_inline, page_size) >Although we don't specify if the size is before compression or after >compression. >At

Re: [PATCH] fstests: btrfs: Check if btrfs will create inline-then-regular file extents

On Wed, Apr 5, 2017 at 5:00 PM, Filipe Manana <fdman...@gmail.com> wrote: > On Wed, Apr 5, 2017 at 3:14 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: >> Btrfs allows inline file extent if and only if >> 1) It's at offset 0 >> 2) It's smaller than min(max_inline, p

Re: [PATCH] Btrfs: fix file corruption after cloning inline extents

On Fri, Mar 3, 2017 at 12:36 AM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Mar 02, 2017 at 02:18:21PM -0800, Liu Bo wrote: >> On Tue, Jul 14, 2015 at 04:34:48PM +0100, fdman...@kernel.org wrote: >> > From: Filipe Manana <fdman...@suse.com> >> > >>

Re: [PATCH v2] qgroup: Retry after commit on getting EDQUOT

On Sat, Mar 11, 2017 at 11:02 PM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > We are facing the same problem with EDQUOT which was experienced with > ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but > here is a fix. Let me

Re: [PATCH v2] qgroup: Retry after commit on getting EDQUOT

On Mon, Mar 13, 2017 at 12:27 PM, Goldwyn Rodrigues <rgold...@suse.de> wrote: > > > On 03/13/2017 07:14 AM, Filipe Manana wrote: >> On Sat, Mar 11, 2017 at 11:02 PM, Goldwyn Rodrigues <rgold...@suse.de> wrote: >>> From: Goldwyn Rodrigues <rgold...@suse.com&

Re: [PATCH v3] qgroup: Retry after commit on getting EDQUOT

On Tue, Mar 14, 2017 at 10:23 AM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > We are facing the same problem with EDQUOT which was experienced with > ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but > here is a fix. Let me

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

On Sun, Feb 19, 2017 at 1:30 PM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > We are facing the same problem with EDQUOT which was experienced with > ENOSPC. Not sure if we require a full ticketing system such as ENOSPC, but > here is a fix. Let me

Re: [PATCH v6 2/2] btrfs: Handle delalloc error correctly to avoid ordered extent hang

ill be handled like: > > |<-- delalloc range --->| > | OE 1 | OE 2 | ... | OE n | > |<>|< --->|<-- old error handler ->| > || || > || \_=> Cleaned up by cleanup_ordered_extents() >

Re: [PATCH v6 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

handler after increasing the iteration offset, so that > cleanup range won't cover any created ordered extent. > > |<-- delalloc range --->| > | OE 1 | OE 2 | ... | OE n | > |<--- --->|<-- cleanup r

Re: [PATCH] Btrfs: fix file corruption after cloning inline extents

On Fri, Mar 3, 2017 at 6:48 PM, Liu Bo <bo.li@oracle.com> wrote: > On Fri, Mar 03, 2017 at 03:36:36PM +0000, Filipe Manana wrote: >> On Fri, Mar 3, 2017 at 12:36 AM, Liu Bo <bo.li@oracle.com> wrote: >> > On Thu, Mar 02, 2017 at 02:18:21PM -0800, Liu Bo wro

Re: [PATCH v5] btrfs: Handle delalloc error correctly to avoid ordered extent hang

bout compression part. > > After the fix, the clean up will happen like: > > |<--- delalloc range --->| > | Ordered extent 1 | Ordered extent 2 | > |Submitted OK | recloc_clone_csum() error | > |<>|&l

Re: [PATCH v5] btrfs: Handle delalloc error correctly to avoid ordered extent hang

On Fri, Mar 3, 2017 at 12:45 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > At 03/03/2017 01:28 AM, Filipe Manana wrote: >> >> On Tue, Feb 28, 2017 at 2:28 AM, Qu Wenruo <quwen...@cn.fujitsu.com> >> wrote: >>> >>> [BUG] >>> Re

Re: [PATCH v6 2/2] btrfs: Handle delalloc error correctly to avoid ordered extent hang

trfs_endio_direct_write_update_ordered() function, and modify it to >>> act just like btrfs_writepage_endio_hook() but handles specified range >>> other than one page. >>> >>> After fix, delalloc error will be handled like: >>> >>

Re: [PATCH v6 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

On Tue, Mar 7, 2017 at 8:59 PM, Liu Bo wrote: > On Tue, Mar 07, 2017 at 12:49:58PM -0800, Liu Bo wrote: >> On Mon, Mar 06, 2017 at 10:55:46AM +0800, Qu Wenruo wrote: >> > [BUG] >> > When btrfs_reloc_clone_csum() reports error, it can underflow metadata >> > and leads to

Re: [PATCH v2] Btrfs: fix invalid attempt to free reserved space on failure to cow range

On Tue, Mar 7, 2017 at 10:03 PM, Liu Bo <bo.li@oracle.com> wrote: > On Tue, Mar 07, 2017 at 04:24:49AM +, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> When attempting to COW a file range (we are starting writeback and doing

Re: [PATCH] btrfs: add missing memset while reading compressed inline extents

On Wed, Mar 8, 2017 at 3:18 AM, Zygo Blaxell wrote: > From: Zygo Blaxell > > This is a story about 4 distinct (and very old) btrfs bugs. > > Commit c8b978188c ("Btrfs: Add zlib compression support") added > three data corruption bugs

Re: [PATCH v7 2/2] btrfs: Handle delalloc error correctly to avoid ordered extent hang

ill be handled like: > > |<-- delalloc range --->| > | OE 1 | OE 2 | ... | OE n | > |<>|< --->|<-- old error handler ->| > || || > || \_=> Cleaned up by cleanup_ordered_extents() >

Re: [PATCH v7 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

handler after increasing the iteration offset, so that > cleanup range won't cover any created ordered extent. > > |<-- delalloc range --->| > | OE 1 | OE 2 | ... | OE n | > |<--- --->|<-- cleanup range ---

Re: [PATCH 1/2] Btrfs: remove unused delalloc_end parameter

On Tue, Mar 7, 2017 at 4:05 PM, David Sterba <dste...@suse.cz> wrote: > On Mon, Mar 06, 2017 at 11:32:47PM +, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> The delalloc_end parameter for extent_clear_unlock_delalloc() is never

Re: [PATCH] generic: test for number of bytes used by files after buffered writes

On Wed, Apr 5, 2017 at 10:46 AM, Eryu Guan <eg...@redhat.com> wrote: > On Tue, Apr 04, 2017 at 03:23:35AM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> Test that a filesystem's implementation of the stat(2) system call >>

Re: [PATCH v2] Btrfs: fix out of bounds array access while reading extent buffer

On Wed, Aug 9, 2017 at 5:31 PM, Liu Bo wrote: > There is a cornel case that slip through the checkers in functions > reading extent buffer, ie. > > if (start < eb->len) and (start + len > eb->len), > then > > a) map_private_extent_buffer() returns immediately because > it's

Re: [PATCH] Btrfs: fix write corruption due to bio cloning on raid5/6

On Thu, Jul 13, 2017 at 5:36 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Jul 13, 2017 at 03:09:54PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> The recent changes to make bio cloning faster (added in t

Re: [PATCH] Btrfs: fix write corruption due to bio cloning on raid5/6

On Thu, Jul 13, 2017 at 7:00 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Jul 13, 2017 at 10:06:32AM -0700, Liu Bo wrote: >> On Thu, Jul 13, 2017 at 05:46:13PM +0100, Filipe Manana wrote: >> > On Thu, Jul 13, 2017 at 5:36 PM, Liu Bo <bo.li@oracle.com> wrot

Re: [PATCH] Btrfs: fix write corruption due to bio cloning on raid5/6

On Thu, Jul 13, 2017 at 11:38 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Jul 13, 2017 at 09:36:19AM -0700, Liu Bo wrote: >> On Thu, Jul 13, 2017 at 03:09:54PM +0100, fdman...@kernel.org wrote: >> > From: Filipe Manana <fdman...@suse.com> >> > >

Re: [PATCH] Btrfs: fix write corruption due to bio cloning on raid5/6

On Thu, Jul 13, 2017 at 8:09 PM, Liu Bo <bo.li@oracle.com> wrote: > On Thu, Jul 13, 2017 at 07:11:24PM +0100, Filipe Manana wrote: >> On Thu, Jul 13, 2017 at 7:00 PM, Liu Bo <bo.li@oracle.com> wrote: >> > On Thu, Jul 13, 2017 at 10:06:32AM -0700, Liu Bo wro

Re: [PATCH 2/2] btrfs: Simplify btrfs_alloc_dev_extent

On Thu, Jul 27, 2017 at 6:36 PM, Nikolay Borisov wrote: > Currently btrfs_alloc_dev_extent essentially open codes btrfs_insert_item. So > let's remove the superfluous code, leaving only the important bits, namely > initialising the device extent and just calling

Re: [PATCH 2/2] btrfs: Simplify btrfs_alloc_dev_extent

On Fri, Jul 28, 2017 at 6:59 AM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 27.07.2017 20:57, Filipe Manana wrote: >> On Thu, Jul 27, 2017 at 6:36 PM, Nikolay Borisov <nbori...@suse.com> wrote: >>> Currently btrfs_alloc_dev_extent essentially o

Re: [PULL] Btrfs, updates for 4.12

On Wed, Apr 19, 2017 at 12:35 PM, David Sterba wrote: > Hi, > > this is the main part of my 4.12 pull, condensed changelog below. I might send > another pull with low-risk patches, mostly cleanups, but so far I'm done with > base testing now. We had a high-churn cycle last time,

Re: [PATCH] fstests: regression test for nocsum buffered read's repair

On Wed, Apr 26, 2017 at 9:54 PM, Liu Bo wrote: > This is to test whether buffered read retry-repair code is able to work in > raid1 case as expected. > > Please note that without checksum, btrfs doesn't know if the data used to > repair is correct, so repair is more of

Re: [PATCH v2] fstests: regression test for btrfs dio read repair

On Wed, Apr 26, 2017 at 7:09 PM, Liu Bo wrote: > This case tests whether dio read can repair the bad copy if we have > a good copy. > > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > introduced the regression. > > The upstream fix is >

Re: [PATCH v2] fstests: regression test for btrfs buffered read's repair

On Wed, Apr 26, 2017 at 7:09 PM, Liu Bo wrote: > This case tests whether buffered read can repair the bad copy if we > have a good copy. > > Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed > and drop checks") introduced the regression. > > The upstream

Re: [PATCH] fstests: regression test for nocsum dio read's repair

On Wed, Apr 26, 2017 at 9:54 PM, Liu Bo wrote: > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > introduced this regression. It'd cause 'Segmentation fault' error. > > The upstream fix is > Btrfs: fix segment fault when doing dio read

Re: [PATCH] Btrfs: fix out of bounds array access while reading extent buffer

On Mon, Aug 7, 2017 at 8:39 PM, Liu Bo wrote: > There is a cornel case that slip through the checkers in functions > reading extent buffer, ie. > > if (start < eb->len) and (start + len > eb->len), > then > > a) map_private_extent_buffer() returns immediately because > it's

Re: [PATCH v3 46/49] fs/btrfs: convert to bio_for_each_segment_all_sp()

On Tue, Aug 8, 2017 at 9:45 AM, Ming Lei wrote: > Cc: Chris Mason > Cc: Josef Bacik > Cc: David Sterba > Cc: linux-btrfs@vger.kernel.org > Signed-off-by: Ming Lei Can you please add some meaningful

Re: [PATCH v2] Btrfs: fix out of bounds array access while reading extent buffer

g proper checks in order to avoid invalid memory access, > ie. 'general protection fault', before it's too late. > > Signed-off-by: Liu Bo <bo.li@oracle.com> Reviewed-by: Filipe Manana <fdman...@suse.com> > --- > > v2: Improve the commit log to clarify that this c

Re: [PATCH] Btrfs: fix out of bounds array access while reading extent buffer

On Tue, Aug 8, 2017 at 6:05 PM, Liu Bo <bo.li@oracle.com> wrote: > Hi Filipe, > > On Tue, Aug 08, 2017 at 09:47:21AM +0100, Filipe Manana wrote: >> On Mon, Aug 7, 2017 at 8:39 PM, Liu Bo <bo.li@oracle.com> wrote: >> > There is a cornel case that sl

Re: ERROR: rename o3528-7220-0 -> usr failed: Directory not empty

On Tue, May 2, 2017 at 3:52 AM, J. Hart <jfhart...@gmail.com> wrote: > On 05/01/2017 02:52 PM, Filipe Manana wrote: >> >> On Mon, May 1, 2017 at 4:17 PM, J. Hart <jfhart...@gmail.com> wrote: >> Just use "btrfs-image -c 9 /dev/whatever image_file",

Re: [PATCH] Btrfs: fix invalid extent maps due to hole punching

On Tue, May 30, 2017 at 9:50 PM, Omar Sandoval <osan...@osandov.com> wrote: > On Sun, May 28, 2017 at 05:31:53PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> > > [snip] > > Hey, Filipe, > > I saw this warning and tried to

Re: [PATCH 6/7] Btrfs: __tree_mod_log_insert decrease max compare count

On Wed, Jun 7, 2017 at 1:58 AM, Timofey Titovets wrote: > In worst case code do 4 comparison, > just add some new checks to switch check branch faster > now in worst case code do 3 comparison Some comments below. > > Signed-off-by: Timofey Titovets >

Re: [PATCH v2] Btrfs: fix invalid extent maps due to hole punching

On Wed, May 31, 2017 at 9:32 PM, Liu Bo <bo.li@oracle.com> wrote: > On Sun, May 28, 2017 at 10:31:05PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> While punching a hole in a range that is not aligned with the sector size &

Re: regression in 4.12 caused by a7e3b975a0f9 ("Btrfs: fix reported number of inode blocks")

On Wed, Jun 14, 2017 at 8:24 AM, Nikolay Borisov wrote: > Hello Filipe, > > It seems the above commit causes various underflows in > some btrfs internal counters. This is evident during generic/439 running: Yes, it's evident - I wrote that test recently to fix a bug that

Re: ERROR: rename o3528-7220-0 -> usr failed: Directory not empty

On Mon, May 1, 2017 at 4:17 PM, J. Hart wrote: > I've got more information on the following error : > > At subvol /mnt/ArchPri/backup/primary/thinkcentre/root/backup.0.2 > At snapshot backup.0.2017.04.21.03.11.40 > ERROR: rename o3528-7220-0 -> usr failed: Directory not empty

Re: [PATCH v2] fstests: regression test for nocsum buffered read's repair

ack repair during read > > Signed-off-by: Liu Bo <bo.li@oracle.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Just a comment below. > --- > v2: - Add 'mkfs -b 1G' to limit filesystem size to 2G in raid1 profile so that > we get a consistent output. > > te

Re: [PATCH v3] fstests: regression test for btrfs dio read repair

egression. > > The upstream fix is > Btrfs: fix invalid dereference in btrfs_retry_endio > > Signed-off-by: Liu Bo <bo.li@oracle.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Just a comment below. > --- > v2: - Add regression commit and the fix to the des

Re: [PATCH v2] fstests: regression test for nocsum dio read's repair

gment fault when doing dio read > > Signed-off-by: Liu Bo <bo.li@oracle.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Just a comment below. > --- > v2: - Add 'mkfs -b 1G' to limit filesystem size to 2G in raid1 profile so that >

Re: [PATCH v3] fstests: regression test for btrfs buffered read's repair

he regression. > > The upstream fix is > Btrfs: bring back repair during read > > Signed-off-by: Liu Bo <bo.li@oracle.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Just a comment below. > --- > v2: - Add regression commit and the fix to the des

Re: [PULL] Btrfs for 4.13, part 1

On Mon, Jun 26, 2017 at 5:58 PM, Chris Mason wrote: > On 06/23/2017 11:16 AM, David Sterba wrote: >> >> Hi, >> >> this is the main batch for 4.13. There are some user visible changes, see >> below. The core updates improve error handling (mostly related to bios), >> with >> the usual

Re: [PATCH] btrfs: fix validation of XATTR_ITEM dir items

On Wed, Jun 21, 2017 at 4:46 PM, David Sterba wrote: > The XATTR_ITEM is a type of a directory item so we use the common > validator helper. We have to adjust the limits because of potential > data_len (ie. the xattr value), which is otherwise 0 for other directory > items. Did

Re: [PATCH] Btrfs: incremental send, apply asynchronous page cache readahead

On Wed, Sep 13, 2017 at 7:38 AM, peterh wrote: > From: Kuanling Huang > > By analyzing the perf on btrfs send, we found it take large > amount of cpu time on page_cache_sync_readahead. This effort > can be reduced after switching to asynchronous one.

Re: [PATCH 2/2] btrfs: extent-tree: Ensure btrfs_trim_fs can trim the whole fs

On Tue, Nov 21, 2017 at 7:21 AM, Qu Wenruo wrote: > [BUG] > fstrim on some btrfs only trims the unallocated space, not trimming any > space in existing block groups. > > [CAUSE] > fstrim_range passed in by default fstrim will be: > > range->start = 0 > range->len = fs_size (which

Re: [PATCH v2] Btrfs: add support for fallocate's zero range operation

On Fri, Nov 3, 2017 at 10:29 AM, Filipe Manana <fdman...@kernel.org> wrote: > On Fri, Nov 3, 2017 at 9:30 AM, Nikolay Borisov <nbori...@suse.com> wrote: >> >> >> On 25.10.2017 17:59, fdman...@kernel.org wrote: >>> From: Filipe Manana <fdman...@suse.

Re: [PATCH] btrfs: Move leaf verification to correct timing to avoid false panic for sanity test

On Thu, Nov 2, 2017 at 7:04 AM, Qu Wenruo wrote: > [BUG] > If we run btrfs with CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y, it will > instantly cause kernel panic like: > > -- > ... > assertion failed: 0, file: fs/btrfs/disk-io.c, line: 3853 > ... > Call Trace: >

Re: [PATCH v2] Btrfs: add support for fallocate's zero range operation

On Fri, Nov 3, 2017 at 9:30 AM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 25.10.2017 17:59, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> This implements support the zero range operation of fallocate. For now >&

Re: [PATCH v2] Btrfs: add support for fallocate's zero range operation

On Wed, Nov 1, 2017 at 10:34 AM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 25.10.2017 17:59, fdman...@kernel.org wrote: >> From: Filipe Manana <fdman...@suse.com> >> >> This implements support the zero range operation of fallocate. For now >&

Re: [PATCH] btrfs: switch uuid tree semaphore to mutex

On Mon, Nov 6, 2017 at 6:24 PM, David Sterba wrote: > The uuid_tree_rescan_sem is used as a mutex (initialized with value 1 > and with at most one active user), no reason to obscure that as a > semaphore. > > Signed-off-by: David Sterba > --- >

Re: [PATCH] Btrfs : send, truncate first to enhance many small files

On Mon, Dec 4, 2017 at 11:28 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 2017年12月04日 19:13, Filipe Manana wrote: >> On Mon, Dec 4, 2017 at 7:19 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >>> >>> >>> On 2017年12月04日 15:02, robbi

Re: [PATCH] Btrfs : send, truncate first to enhance many small files

On Mon, Dec 4, 2017 at 7:19 AM, Qu Wenruo wrote: > > > On 2017年12月04日 15:02, robbieko wrote: >> From: Robbie Ko >> >> The commands generated by send contain the following step: >> 1. mkfile o1851-19-0 >> 2. rename o1851-19-0 ->

Re: [PATCH v2 2/2] btrfs: incremental send, improve rmdir performance for large directory

as the > starting point for future calls to can_rmdir(). > > Signed-off-by: Robbie Ko <robbi...@synology.com> Reviewed-by: Filipe Manana <fdman...@suse.com> > --- > V2: > fix comments > split optimization allocations orphan_dir_info > > fs/btrfs/send.c | 31

Re: [PATCH v2 1/2] btrfs: incremental send, optimization add orphan_dir_info

On Tue, May 8, 2018 at 11:11 AM, robbieko <robbi...@synology.com> wrote: > From: Robbie Ko <robbi...@synology.com> > > moving the allocation to the end in order to avoid unnecessary > allocations > > Signed-off-by: Robbie Ko <robbi...@synology.com> Reviewed-

Re: [PATCH v3] btrfs: incremental send, fix BUG when invalid memory access

reempt_curr+0x57/0x90 > [] ? do_vfs_ioctl+0x4aa/0x990 > [] ? do_fork+0x113/0x3b0 > [] ? trace_hardirqs_off_thunk+0x3a/0x6c > [] ? SyS_ioctl+0x88/0xa0 > [] ? system_call_fastpath+0x16/0x1b > ---[ end trace 29576629ee80b2e1 ]--- > > Signed-off-by: Robbie Ko <robbi.

Re: [PATCH] btrfs: incremental send, fix BUG when parent commit_root changed

On Wed, May 9, 2018 at 2:10 AM, robbieko <robbi...@synology.com> wrote: > Filipe Manana 於 2018-05-08 19:12 寫到: >> >> On Tue, May 8, 2018 at 11:30 AM, robbieko <robbi...@synology.com> wrote: >>> >>> Hi Filipe Manana, >>> >>>

Re: [PATCH] btrfs: incremental send, fix BUG when parent commit_root changed

On Tue, May 8, 2018 at 9:15 AM, robbieko wrote: > From: Robbie Ko > > [BUG] > btrfs send BUG on parent commit_root node receive destination > is at the same volume. I can't make sense of that sentence. > > [Example] > btrfs send -e -p /mnt/snap1/

Re: [PATCH] btrfs: send, improve rmdir performance for large directory

On Tue, May 8, 2018 at 3:50 AM, robbieko wrote: > From: Robbie Ko > > At present, we check if the directory can be deleted. At present, and in the future... it will always be needed. > We need to check whether all the files under this directory >

Re: [PATCH 1/3] btrfs: qgroups, fix rescan worker running races

On Thu, Apr 26, 2018 at 8:23 PM, wrote: > From: Jeff Mahoney > > Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization) > fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but > ended up reintroducing the hang-on-unmount bug that the

Re: [PATCH 10/10] Btrfs: reserve space for O_TMPFILE orphan item deletion

n_block_rsv it wasn't using it. > > Fixes: ef3b9af50bfa ("Btrfs: implement inode_operations callback tmpfile") > Signed-off-by: Omar Sandoval <osan...@fb.com> Reviewed-by: Filipe Manana <fdman...@suse.com> > --- > fs/btrfs/inode.c | 3 ++- > 1 file changed, 2

Re: [PATCH v2] btrfs: incremental send, fix BUG when invalid memory access

On Fri, May 11, 2018 at 7:34 AM, robbieko wrote: > From: Robbie Ko > > [BUG] > btrfs incremental send BUG happens when creating a snapshot of snapshot > that is being used by send. > > [REASON] > The problem can happen if while we are doing a send

Re: Strange behavior (possible bugs) in btrfs

On Mon, Apr 30, 2018 at 5:04 PM, Vijay Chidambaram wrote: > Hi, > > We found two more cases where the btrfs behavior is a little strange. > In one case, an fsync-ed file goes missing after a crash. In the > other, a renamed file shows up in both directories after a crash. > >

Re: [PATCH] btrfs: use kvzalloc for EXTENT_SAME temporary data

On Fri, May 11, 2018 at 5:49 PM, David Sterba <dste...@suse.cz> wrote: > On Fri, May 11, 2018 at 05:25:50PM +0100, Filipe Manana wrote: >> On Fri, May 11, 2018 at 4:57 PM, David Sterba <dste...@suse.com> wrote: >> > The dedupe range is 16 MiB, with 4KiB pages and 8

Re: [PATCH] btrfs: use kvzalloc for EXTENT_SAME temporary data

On Fri, May 11, 2018 at 4:57 PM, David Sterba wrote: > The dedupe range is 16 MiB, with 4KiB pages and 8 byte pointers, the > arrays can be 32KiB large. To avoid allocation failures due to > fragmented memory, use the allocation with fallback to vmalloc. > > Signed-off-by: David

Re: [PATCH] btrfs: incremental send, fix BUG when parent commit_root changed

On Tue, May 8, 2018 at 11:30 AM, robbieko <robbi...@synology.com> wrote: > Hi Filipe Manana, > > Although the snapshot is readonly, when the snapshot is created, > in order to modify the last_snapshot, it will cause generation changes, > and it will affect the commit_root m

Re: Strange behavior (possible bugs) in btrfs

On Mon, Apr 30, 2018 at 5:04 PM, Vijay Chidambaram wrote: > Hi, > > We found two more cases where the btrfs behavior is a little strange. > In one case, an fsync-ed file goes missing after a crash. In the > other, a renamed file shows up in both directories after a crash. > >

Re: [PATCH 1/4] btrfs: always wait on ordered extents at fsync time

On Wed, May 23, 2018 at 4:58 PM, Josef Bacik wrote: > From: Josef Bacik > > There's a priority inversion that exists currently with btrfs fsync. In > some cases we will collect outstanding ordered extents onto a list and > only wait on them at the very last

Re: [PATCH] Btrfs: fix the corruption by reading stale btree blocks

r to get a valid parent transid, we need to hold the parent's > lock until finish reading child. > > Signed-off-by: Liu Bo <bo@linux.alibaba.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Looks good, great finding and explanation. > --- > fs/btrfs/ctree.c | 6 ++

Re: 4.15.6 crash: BUG at fs/btrfs/ctree.c:1862

On Tue, May 15, 2018 at 12:10 AM, Marc MERLIN wrote: > static noinline struct extent_buffer * > read_node_slot(struct btrfs_fs_info *fs_info, struct extent_buffer *parent, >int slot) > { > int level = btrfs_header_level(parent); > struct

Re: [PATCH 2/2] btrfs: always wait on ordered extents at fsync time

we had to do around getting > the right checksums. Killing all of this makes our lives easier and > gets rid of the priority inversion. Much easier! > > Signed-off-by: Josef Bacik <jba...@fb.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Looks good to me. Happy to s

Re: [GIT PULL] Btrfs updates for 4.18

On Mon, Jun 4, 2018 at 4:43 PM, David Sterba wrote: > Hi, > > there are some new features and a usual load of cleanups, more details below. > > Specifically, there's a set of new non-privileged ioctls to allow > subvolume listing. It works but still needs a security review as it's a > new

Re: [PATCH 2/2] Btrfs: sync log after logging new name

On Fri, Jun 15, 2018 at 4:54 PM, David Sterba wrote: > On Mon, Jun 11, 2018 at 07:24:28PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana >> Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes") >> Reported-by: Vijay Chidambaram

Re: [GIT PULL] Btrfs updates for 4.18

On Mon, Jun 11, 2018 at 9:14 AM, Anand Jain wrote: > > > On 06/10/2018 12:21 AM, Filipe Manana wrote: >> >> On Mon, Jun 4, 2018 at 4:43 PM, David Sterba wrote: >>> >>> Hi, >>> >>> there are some new features and a usual load of cleanu

Re: [PATCH] Btrfs: fix mount failure when qgroup rescan is in progress

On Wed, Jun 27, 2018 at 4:44 PM, Nikolay Borisov wrote: > > > On 27.06.2018 02:43, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> If a power failure happens while the qgroup rescan kthread is running, >> the next mount operation will always

Re: [PATCH] Btrfs: fix mount failure when qgroup rescan is in progress

On Wed, Jun 27, 2018 at 4:55 PM, Nikolay Borisov wrote: > > > On 27.06.2018 18:45, Filipe Manana wrote: >> On Wed, Jun 27, 2018 at 4:44 PM, Nikolay Borisov wrote: >>> >>> >>> On 27.06.2018 02:43, fdman...@kernel.org wrote: >>>> From: Fil

Re: [PATCH v3] btrfs: Don't remove block group still has pinned down bytes

On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote: > [BUG] > Under certain KVM load and LTP tests, we are possible to hit the > following calltrace if quota is enabled: > -- > BTRFS critical (device vda2): unable to find logical 8820195328 length 4096 > BTRFS critical (device vda2): unable to

Re: [PATCH] Btrfs: fix physical offset reported by fiemap for inline extents

On Wed, Jun 20, 2018 at 3:55 AM, robbieko wrote: > fdman...@kernel.org 於 2018-06-19 19:31 寫到: > >> From: Filipe Manana >> >> Commit 9d311e11fc1f ("Btrfs: fiemap: pass correct bytenr when >> fm_extent_count is zero") introduced a regression where we no l

Re: [PATCH v3] btrfs: Don't remove block group still has pinned down bytes

On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote: > > > On 2018年06月20日 17:13, Filipe Manana wrote: >> On Fri, Jun 15, 2018 at 2:35 AM, Qu Wenruo wrote: >>> [BUG] >>> Under certain KVM load and LTP tests, we are possible to hit the >>&g

Re: [PATCH] btrfs: not a disk error if the bio_add_page fails

On Wed, Jan 3, 2018 at 8:07 AM, Anand Jain wrote: > bio_add_page() can fail for logical reasons as from the bio_add_page() > comments:- 'This will only fail if either > bio->bi_vcnt == bio->bi_max_vecs or it's a cloned bio.' Don't inc the > write error statistics for this.

Re: [PATCH] Btrfs: replace raid56 stripe bubble sort with insert sort

On Thu, Dec 28, 2017 at 3:28 PM, Timofey Titovets wrote: > Insert sort are generaly perform better then bubble sort, > by have less iterations on avarage. > That version also try place element to right position > instead of raw swap. > > I'm not sure how many stripes per bio

Re: [PATCH] Btrfs: replace raid56 stripe bubble sort with insert sort

On Wed, Jan 3, 2018 at 3:39 PM, Timofey Titovets <nefelim...@gmail.com> wrote: > 2018-01-03 14:40 GMT+03:00 Filipe Manana <fdman...@gmail.com>: >> On Thu, Dec 28, 2017 at 3:28 PM, Timofey Titovets <nefelim...@gmail.com> >> wrote: >>> Insert sort ar

Re: [PATCH] btrfs: qgroup: Fix root item corruption when multiple same source snapshiots are created with quota enabled

t; > Fix it by forcing recording source subvolume in current transaction > before qgroup sub-transaction commit. > > Reported-by: Justin Maggard <jmagg...@netgear.com> > Signed-off-by: Qu Wenruo <w...@suse.com> Reviewed-by: Filipe Manana <fdman...@suse.com> Looks goo

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 1:10 PM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 21.02.2018 15:06, Filipe Manana wrote: >> On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov <nbori...@suse.com> wrote: >>> Currently the DIO read cases uses a botched idea fr

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov wrote: > Currently the DIO read cases uses a botched idea from ext4 to ensure > that DIO reads don't race with truncate. The idea is that if we have a > pending truncate we set BTRFS_INODE_READDIO_NEED_LOCK which in turn >

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 2:15 PM, Nikolay Borisov <nbori...@suse.com> wrote: > > > On 21.02.2018 15:51, Filipe Manana wrote: >> On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov <nbori...@suse.com> wrote: >>> Currently the DIO read cases uses a botched idea fr

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 11:41 AM, Nikolay Borisov wrote: > Currently the DIO read cases uses a botched idea from ext4 to ensure > that DIO reads don't race with truncate. The idea is that if we have a > pending truncate we set BTRFS_INODE_READDIO_NEED_LOCK which in turn >

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 10:38 PM, Liu Bo <bo.li@oracle.com> wrote: > On Wed, Feb 21, 2018 at 07:05:13PM +0000, Filipe Manana wrote: >> On Wed, Feb 21, 2018 at 6:28 PM, Liu Bo <bo.li@oracle.com> wrote: >> > On Wed, Feb 21, 2018 at 02:42:08PM +, Filipe Mana

Re: btrfs crash consistency bug : Blocks allocated beyond eof are lost

On Fri, Feb 23, 2018 at 4:35 PM, Jayashree Mohan wrote: > Hi, > > [Fsync issue in btrfs] > In addition to the above, I would like to bring to your notice that : > After doing a fallocate or fallocate zero_range with keep size option, > a fsync() operation would have no

Re: [PATCH] btrfs: Fix locking during DIO read

On Wed, Feb 21, 2018 at 6:28 PM, Liu Bo <bo.li@oracle.com> wrote: > On Wed, Feb 21, 2018 at 02:42:08PM +0000, Filipe Manana wrote: >> On Wed, Feb 21, 2018 at 2:15 PM, Nikolay Borisov <nbori...@suse.com> wrote: >> > >> > >> > On 21.02.2018 15:51,

Re: [PATCH 1/2] Btrfs: fix return value on rename exchange failure

On Tue, Jun 19, 2018 at 2:38 PM, David Sterba wrote: > On Mon, Jun 11, 2018 at 07:24:16PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> If we failed during a rename exchange operation after starting/joining a >> transaction, we would end up replaci

Re: [PATCH v3] btrfs: Don't remove block group still has pinned down bytes

On Wed, Jun 20, 2018 at 12:03 PM, Qu Wenruo wrote: > > > On 2018年06月20日 17:33, Filipe Manana wrote: >> On Wed, Jun 20, 2018 at 10:22 AM, Qu Wenruo wrote: >>> >>> >>> On 2018年06月20日 17:13, Filipe Manana wrote: >>>> On Fri, Jun 15, 2018 at 2:35

Re: [PATCH v4] btrfs: Don't remove block group still has pinned down bytes

st teach btrfs_delete_unused_bgs() to skip block group who still has > pinned bytes. > > However there is a minor side effect, since currently we only queue > empty blocks at update_block_group(), and such empty block group with > pinned bytes won't go through update_block_group(

Re: [PATCH] Btrfs: optimization to avoid ENOSPC for nocow writes after snapshot when low on data space

tomic_inc(>will_be_snapshotted); > smp_mb__after_atomic(); > /* wait for no snapshot writes */ > @@ -787,6 +792,13 @@ static int create_snapshot(struct btrfs_root *root, > struct inode *dir, > if (ret) > goto dec_and_free

<    1   2   3   4   5   6   7   8   >