Re: [PATCH 1/3] btrfs-progs: Generic functions to retrieve chunks and their bg info

Hi, Working on a v2 of this patch based on the comments received. Thanks, Divya On 06/07/2017 10:03 AM, Goffredo Baroncelli wrote: Hi, any news about these commands ? BR G.Baroncelli On 2016-10-28 17:44, David Sterba wrote: On Mon, Oct 17, 2016 at 05:35:13PM -0700, Divya Indi wrote: An

Re: [PATCH 7/7] Btrfs: warn if total_bytes_pinned is non-zero on unmount

On Wed, Jun 07, 2017 at 01:22:04PM -0700, Liu Bo wrote: > On Tue, Jun 06, 2017 at 04:45:32PM -0700, Omar Sandoval wrote: > > From: Omar Sandoval > > > > Catch any future/remaining leaks or underflows of total_bytes_pinned. > > > > This might be a little bit late, what about

Re: [PATCH 6/7] Btrfs: rework delayed ref total_bytes_pinned accounting

On Wed, Jun 07, 2017 at 01:18:10PM -0700, Liu Bo wrote: > On Tue, Jun 06, 2017 at 04:45:31PM -0700, Omar Sandoval wrote: > > From: Omar Sandoval > > > > The total_bytes_pinned counter is completely broken when accounting > > delayed refs: > > > > - If two drops for the same

[PATCH 0/2] cleanup write_dev_flush()

Commit 9035b5dbc576 btrfs: btrfs_io_bio_alloc never fails, skip error handling has removed ENOMEM in write_dev_flush() so the below two patches adds its related cleanups. This patch is on top of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next But without the

[PATCH 1/2] btrfs: write_dev_flush does not return ENOMEM anymore

Commit 9035b5dbc576 btrfs: btrfs_io_bio_alloc never fails, skip error handling removed the -ENOMEM return from write_dev_flush() so no need to check for the -ENOMEM during send. This patch also peals write_dev_flush's wait part of the code, and creates a new function wait_dev_flush().

[PATCH 2/2] btrfs: flush error also accounts for its send error

So remove the static check of send error Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index d8151839bb3d..682c494dbc7f 100644 ---

Re: [PATCH] btrfs: Convert btrfs_fs_info's free_chunk_space to an atomic64_t

On 7.06.2017 21:09, Sargun Dhillon wrote: > This patch is a small performance optimization to get rid of a spin > lock, where instead an atomic64_t can be used. > > Signed-off-by: Sargun Dhillon I've already sent similar patch 1 month ago:

Re: btrfs-convert: whats minimum free space requirement?

On Fri, Jun 09, 2017 at 01:35:12PM +0800, Qu Wenruo wrote: > >ex: Like 5% of ext3/4 free space is needed for > >btrfs-convert to succeed? > > That's hard to say. > > It's not only dependent on how much free space is here, but also how > continuous the free space is. > > In convert, it needs the

btrfs native encryption

Dear btrfs maintainers, Google is evaluating btrfs for its potential use in android, but currently the lack of native file-based encryption unfortunately makes it a nonstarter. According to the FAQ (specifically the answer to "Does btrfs support encryption"), nobody is currently working on this.

Re: btrfs native encryption

On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote: > Dear btrfs maintainers, > Google is evaluating btrfs for its potential use in android, but > currently the lack of native file-based encryption unfortunately makes > it a nonstarter. According to the FAQ (specifically the answer to

Re: dedicated error codes for the block layer V3

On Thu, Jun 08 2017 at 11:42am -0400, Jens Axboe wrote: > On 06/03/2017 01:37 AM, Christoph Hellwig wrote: > > This series introduces a new blk_status_t error code type for the block > > layer so that we can have tigher control and explicit semantics for > > block layer errors.

Re: dedicated error codes for the block layer V3

On Fri, Jun 09 2017, Mike Snitzer wrote: > On Thu, Jun 08 2017 at 11:42am -0400, > Jens Axboe wrote: > > > On 06/03/2017 01:37 AM, Christoph Hellwig wrote: > > > This series introduces a new blk_status_t error code type for the block > > > layer so that we can have tigher

Re: dedicated error codes for the block layer V3

On Sat, Jun 03 2017, Christoph Hellwig wrote: > This series introduces a new blk_status_t error code type for the block > layer so that we can have tigher control and explicit semantics for > block layer errors. > > All but the last three patches are cleanups that lead to the new type. > > The

Re: [PATCH 04/10] fs: Introduce RWF_NOWAIT

On Tue, Jun 06, 2017 at 06:19:33AM -0500, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > RWF_NOWAIT informs kernel to bail out if an AIO request will block > for reasons such as file allocations, or a writeback triggered, > or would block while allocating requests

Re: btrfs-convert: whats minimum free space requirement?

On Fri, Jun 09, 2017 at 03:38:31PM +0800, Qu Wenruo wrote: > >I was thinking about adding a free-space check (based on total blocks/free > >block > >stat from source superblock) before btrfs-convert begins, looks like its more > >complex than i thought. > > BTW, it's already done, since it's

Re: [PATCH 0/10 v11] No wait AIO

On Thu, Jun 08, 2017 at 12:39:10AM -0700, Christoph Hellwig wrote: > As already indicated this whole series looks fine to me. > > Al: are you going to pick this up? Or Andrew? The main issue here is "let's bail out from ->write_iter() instances" patch. It very obviously has holes in coverage.

Re: btrfs native encryption

On Fri, Jun 9, 2017 at 9:50 AM, Filip Bystricky wrote: > Dear btrfs maintainers, > Google is evaluating btrfs for its potential use in android, but > currently the lack of native file-based encryption unfortunately makes > it a nonstarter. According to the FAQ

Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

Hi, Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't debugged) and I pressed the reset button. The next boot btrfs won't mount: [Fri Jun 9 20:46:07 2017] BTRFS error (device md0): parent transid verify failed on 5840011722752 wanted 170755 found 170832 [Fri Jun 9

[PATCH] btrfs-progs: Fix an infinite loop in btrfs_next_bg

I've run into a couple filesystems where btrfs-find-root would spin indefinitely. If the first cache extent start location is 0, we end up in an infinite loop in btrfs_next_bg(). Fix it by checking for that situation, and jumping to the next bg if necessary. Fixes: e2e0dae9 (btrfs-progs:

Re: [PULL] Btrfs fixes for 4.12

On 06/05/2017 01:47 PM, David Sterba wrote: Hi, please pull the following assorted fixes to 4.12. Thanks. The following changes since commit 9bcaaea7418d09691f1ffab5c49aacafe3eef9d0: btrfs: fix the gfp_mask for the reada_zones radix tree (2017-05-04 16:56:11 -0700) are available in the

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote: > Hi, > > Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't > debugged) and I pressed the reset button. The next boot btrfs won't mount: > > [Fri Jun 9 20:46:07 2017] BTRFS error (device md0): parent transid

Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

Op 09-06-17 om 21:57 schreef Hugo Mills: > On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote: >> Hi, >> >> Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't >> debugged) and I pressed the reset button. The next boot btrfs won't mount: >> >> [Fri Jun 9 20:46:07