Re: spinning kworker with space_cache=v2 searching for free space

Am 12.11.2016 um 03:18 schrieb Liu Bo: > On Wed, Nov 09, 2016 at 09:19:21PM +0100, Stefan Priebe - Profihost AG wrote: >> Hello, >> >> found this one from 2014: >> https://patchwork.kernel.org/patch/5551651/ >> >> it this still valid? > > The space cache code doesn't change a lot, so I think the

Re: when btrfs scrub reports errors and btrfs check --repair does not

On Fri, Nov 11, 2016 at 11:55:21AM +0800, Qu Wenruo wrote: > It seems to be orphan inodes. > Btrfs doesn't remove all the contents of an inode at rm time. > It just unlink the inode and put it into a state called orphan inodes.(Can't > be referred from any directory). BTRFS warning (device dm-6):

Re: spinning kworker with space_cache=v2 searching for free space

On Wed, Nov 09, 2016 at 09:19:21PM +0100, Stefan Priebe - Profihost AG wrote: > Hello, > > found this one from 2014: > https://patchwork.kernel.org/patch/5551651/ > > it this still valid? The space cache code doesn't change a lot, so I think the patch is still valid to apply(there might be some

[PATCH v3-onstack] btrfs: make block group flags in balance printks human-readable

They're not even documented anywhere, letting users with no recourse but to RTFS. It's no big burden to output the bitfield as words. Also, display unknown flags as hex. Signed-off-by: Adam Borowski --- fs/btrfs/relocation.c | 41 ++---

[PATCH] fstests: generic/098 update test for truncating a file into the middle of a hole

This updates generic/098 by adding a sync option, i.e. 'sync' after the second write, and with btrfs's NO_HOLES, we could still get wrong isize after remount. This gets fixed by the patch 'Btrfs: fix truncate down when no_holes feature is enabled' Signed-off-by: Liu Bo

[PATCH] Btrfs: fix truncate down when no_holes feature is enabled

For such a file mapping, [0-4k][hole][8k-12k] In NO_HOLES mode, we don't have the [hole] extent any more. Commit c1aa45759e90 ("Btrfs: fix shrinking truncate when the no_holes feature is enabled") fixed disk isize not being updated in NO_HOLES mode when data is not flushed. However, even if

Re: [PULL] Btrfs fixes for 4.9-rc5

On 11/10/2016 10:00 AM, David Sterba wrote: Hi, two minor error handling fixes and one fix for balance sttus item that goes back to 4.4. The branch continues from my last pull that went to Linus' tree, so it would be a good idea to do the same as before. I've added a signed tag for branch.

Re: [RFC] btrfs: make max inline data can be equal to sectorsize

On Tue, Oct 11, 2016 at 02:47:42PM +0800, Wang Xiaoguang wrote: > If we use mount option "-o max_inline=sectorsize", say 4096, indeed > even for a fresh fs, say nodesize is 16k, we can not make the first > 4k data completely inline, I found this conditon causing this issue: > !compressed_size &&

Re: bi_vcnt checks for repair

On Thu, Nov 10, 2016 at 12:06:01PM -0800, Christoph Hellwig wrote: > Hi all, > > btrfs_check_repairable and bio_readpage_error have somewhat odd > looking check for bi_vcnt, checking on how to proceed based on that. > > Does anyone remember what they actually are checking for? Depending > on

Re: [PATCH 1/2] btrfs: remove old tree_root dirent processing in btrfs_real_readdir()

On Sat, Nov 05, 2016 at 01:26:34PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > Commit 3de4586c527 (Btrfs: Allow subvolumes and snapshots anywhere > in the directory tree) introduced the current system of placing > snapshots in the directory tree. It also introduced the

Btrfs progs release 4.8.3

Hi, btrfs-progs version 4.8.3 have been released. Handful of fixes and lots of cleanups. Changes: * check: * support for clearing space cache (v1) * size reduction of inode backref structure * send: * fix handling of multiple snapshots (-p and -c options) * transfer buffer

Re: [PATCH 12/13] btrfs: check device for critical errors and mark failed

On Tue, Nov 08, 2016 at 08:18:13PM +0800, Anand Jain wrote: > > This patch is independent of the hot-space as such. Independent patches, not to say important fixes, would get the right attention if they come outside of a large series that introduces a new feature. Features need time to review

Re: Deletion of the CoW snapshots causes BTRFS ENOSPC error.

Hello, Qu. After applying the patch https://patchwork.kernel.org/patch/9319179/, the NOSPC error is repeated on the same scenario. We also noticed that the error appears when the "Data, single: used=4.39TiB" is reached. Details: [root@OraCI2 ~]# uname -a Linux OraCI2.sigma-it.local

Re: [PATCH] Return best entry, if it is the first one

On Thu, Nov 10, 2016 at 09:01:46AM -0600, Goldwyn Rodrigues wrote: > The find_most_right_entry() tends to miss on the best entry if it > is the first one on the list and there are only two entries in the list. > So, we assign both prev and best to entry. > > To do this, the selection process

Re: [PATCH 2/2] btrfs: increment ctx->pos for every emitted or skipped dirent in readdir

On Sat, Nov 05, 2016 at 01:26:35PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > If we process the last item in the leaf and hit an I/O error while > reading the next leaf, we return -EIO without having adjusted the > position. Since we have emitted dirents, getdents()

Re: [PATCH 1/2] btrfs: remove old tree_root dirent processing in btrfs_real_readdir()

On Sat, Nov 05, 2016 at 01:26:34PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > Commit 3de4586c527 (Btrfs: Allow subvolumes and snapshots anywhere > in the directory tree) introduced the current system of placing > snapshots in the directory tree. It also introduced the

[PATCH 1/3] btrfs: improve inode's outstanding_extents computation

This issue was revealed by modifying BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, When modifying BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, fsstress test often gets these warnings from btrfs_destroy_inode(): WARN_ON(BTRFS_I(inode)->outstanding_extents);

[PATCH 2/3] btrfs: introduce type based delalloc metadata reserve

Introduce type based metadata reserve parameter for delalloc space reservation/freeing function. The problem we are going to solve is, btrfs use different max extent size for different mount options. For compression, the max extent size is 128K, while for non-compress write it's 128M. And

[PATCH 3/3] btrfs: Introduce COMPRESS reserve type to fix false enospc for compression

When testing btrfs compression, sometimes we got ENOSPC error, though fs still has much free space, xfstests generic/171, generic/172, generic/173, generic/174, generic/175 can reveal this bug in my test environment when compression is enabled. After some debuging work, we found that it's

[PATCH 0/3] introduce type based delalloc metadata reserve to fix some false enospc issues

When having compression enabled, Stefan Priebe ofen got enospc errors though fs still has much free space. Qu Wenruo also has submitted a fstests test case which can reproduce this bug steadily, please see url: https://patchwork.kernel.org/patch/9420527 First patch[1/3] "btrfs: improve inode's