[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 --- a/fs/btrfs/disk-io.c +++ b/fs/btr

[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 namelen-check

[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(). Signed-of

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: https://patchwork.kernel.org/patch/9720999/ > ---

btrfs-convert: whats minimum free space requirement?

Hi. Just wanted to check whether do we have any numbers on whats the minimum free space requirement on source file system for btrfs-convert to work? ex: Like 5% of ext3/4 free space is needed for btrfs-convert to succeed? Cheers. Lakshmipathi.G -- To unsubscribe from this list: send the line

Re: status of swapfiles on Btrfs

On Thu, Jun 08, 2017 at 03:35:10PM -0600, Chris Murphy wrote: > What's the status? I rebased the patches on v4.9 back in November and ran into a circular locking issue between mmap_sem and i_rwsem. I never figured out how to resolve that. Christoph was the last one that I talked to about this, may

status of swapfiles on Btrfs

What's the status? This message gave me an idea: http://www.spinics.net/lists/linux-btrfs/msg40323.html What about an xattr on both subvolume and the swapfile that would inhibit btrfs user space tools from either snapshotting the subvolume or the swapfile? There could be a feature in btrfs user

Re: About free space fragmentation, metadata write amplification and (no)ssd

On 06/08/2017 08:47 PM, Roman Mamedov wrote: > On Thu, 8 Jun 2017 19:57:10 +0200 > Hans van Kranenburg wrote: > >> There is an improvement with subvolume delete + nossd that is visible >> between 4.7 and 4.9. > > I don't remember if I asked before, but did you test on 4.4? No, I jumped from 3.1

Re: About free space fragmentation, metadata write amplification and (no)ssd

On Thu, 8 Jun 2017 19:57:10 +0200 Hans van Kranenburg wrote: > There is an improvement with subvolume delete + nossd that is visible > between 4.7 and 4.9. I don't remember if I asked before, but did you test on 4.4? The two latest longterm series are 4.9 and 4.4. 4.7 should be abandoned and for

Lock between userspace and btrfs-cleaner on extent_buffer

I have a deadlock caught in the wild between two processes -- btrfs-cleaner, and userspace process (Docker). Here, you can see both of the backtraces. btrfs-cleaner is trying to get a lock on 9859d360caf0, which is owned by Docker's pid. Docker on the other hand is trying to get a lock on 9

Re: About free space fragmentation, metadata write amplification and (no)ssd

Ehrm, On 05/28/2017 02:59 AM, Hans van Kranenburg wrote: > A small update... > > Original (long) message: > https://www.spinics.net/lists/linux-btrfs/msg64446.html > > On 04/08/2017 10:19 PM, Hans van Kranenburg wrote: >> [...] >> >> == But! The Meta Mummy returns! == >> >> After changing to nos

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. > > > > All but t

Re: dedicated error codes for the block layer V3

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. > > All but the last three patches are cleanups that lead to the new type. > > The

Investment Interest & Offer

We are a Fund management company located in the United Kingdom, we specialize in searching for potential investments opportunities for our high net-worth clients globally. Should this be of interest to you, please do not hesitate to email me for further information. Thanks Seydou Thieba -- To

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

As already indicated this whole series looks fine to me. Al: are you going to pick this up? Or Andrew? On Tue, Jun 06, 2017 at 06:19:29AM -0500, Goldwyn Rodrigues wrote: > This series adds nonblocking feature to asynchronous I/O writes. > io_submit() can be delayed because of a number of reason: