Re: Linux-next regression?

On 5 Dec 2018, at 5:59, Andrea Gelmini wrote: > On Tue, Dec 04, 2018 at 10:29:49PM +0000, Chris Mason wrote: >> I think (hope) this is: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=201685 >> >> Which was just nailed down to a blkmq bug. It triggers wh

Re: Linux-next regression?

On 28 Nov 2018, at 11:05, Andrea Gelmini wrote: > On Tue, Nov 27, 2018 at 10:16:52PM +0800, Qu Wenruo wrote: >> >> But it's less a concerning problem since it doesn't reach latest RC, >> so >> if you could reproduce it stably, I'd recommend to do a bisect. > > No problem to bisect, usually. >

Re: btrfs development - question about crypto api integration

On 29 Nov 2018, at 12:37, Nikolay Borisov wrote: > On 29.11.18 г. 18:43 ч., Jean Fobe wrote: >> Hi all, >> I've been studying LZ4 and other compression algorithms on the >> kernel, and seen other projects such as zram and ubifs using the >> crypto api. Is there a technical reason for not

Re: [PATCH 2/3] btrfs: wakeup cleaner thread when adding delayed iput

On 28 Nov 2018, at 14:06, David Sterba wrote: > On Tue, Nov 27, 2018 at 03:08:08PM -0500, Josef Bacik wrote: >> On Tue, Nov 27, 2018 at 07:59:42PM +0000, Chris Mason wrote: >>> On 27 Nov 2018, at 14:54, Josef Bacik wrote: >>> >>>> On Tue, Nov 27, 2018 at

Re: [PATCH 2/3] btrfs: wakeup cleaner thread when adding delayed iput

On 27 Nov 2018, at 14:54, Josef Bacik wrote: > On Tue, Nov 27, 2018 at 10:26:15AM +0200, Nikolay Borisov wrote: >> >> >> On 21.11.18 г. 21:09 ч., Josef Bacik wrote: >>> The cleaner thread usually takes care of delayed iputs, with the >>> exception of the btrfs_end_transaction_throttle path. The

Re: [PATCH v2] Btrfs: fix missing delayed iputs on unmount

On 1 Nov 2018, at 12:00, Omar Sandoval wrote: > On Thu, Nov 01, 2018 at 04:29:48PM +0100, David Sterba wrote: >>> >>> How is that? kthread_stop() frees the task struct, so >>> wake_up_process() >>> would be a use-after-free. >> >> That was an assumption for the demonstration purposes, the

Re: [PATCH v2] Btrfs: fix missing delayed iputs on unmount

On 1 Nov 2018, at 6:15, David Sterba wrote: > On Wed, Oct 31, 2018 at 10:06:08AM -0700, Omar Sandoval wrote: >> From: Omar Sandoval >> >> There's a race between close_ctree() and cleaner_kthread(). >> close_ctree() sets btrfs_fs_closing(), and the cleaner stops when it >> sees it set, but this

Re: [PATCH] btrfs: use tagged writepage to mitigate livelock of snapshot

On 1 Nov 2018, at 6:21, ethanlien wrote: > Nikolay Borisov 於 2018-11-01 18:01 寫到: >> On 1.11.18 г. 11:56 ч., ethanlien wrote: >>> Nikolay Borisov 於 2018-11-01 16:59 寫到: On 1.11.18 г. 8:49 ч., Ethan Lien wrote: > Snapshot is expected to be fast. But if there are writers steadily >

Re: [PATCH 0/2] address lock contention of btree root

On 21 Aug 2018, at 14:15, Liu Bo wrote: On Tue, Aug 21, 2018 at 01:54:11PM -0400, Chris Mason wrote: On 16 Aug 2018, at 17:07, Liu Bo wrote: The lock contention on btree nodes (esp. root node) is apparently a bottleneck when there're multiple readers and writers concurrently trying to access

Re: [PATCH 0/2] address lock contention of btree root

On 16 Aug 2018, at 17:07, Liu Bo wrote: The lock contention on btree nodes (esp. root node) is apparently a bottleneck when there're multiple readers and writers concurrently trying to access them. Unfortunately this is by design and it's not easy to fix it unless with some complex changes,

Re: Do btrfs compression option changes need to be atomic?

On 21 Aug 2018, at 9:46, David Howells wrote: Should changes to the compression options on a btrfs mount be atomic, the problem being that they're split across three variables? Further to that, how much of an issue is it if the configuration is split out into its own struct that is accessed

[PATCH v2] Btrfs: fix regression in btrfs_page_mkwrite() from vm_fault_t conversion

turn type of btrfs_page_mkwrite to vm_fault_t) Signed-off-by: Chris Mason --- Changes since v1: don't set the vmfault_t 'ret' to zero, just move our goto taret around around instead. fs/btrfs/inode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c inde

Re: [PATCH] Btrfs: fix regression in btrfs_page_mkwrite() from vm_fault_t conversion

On 25 Jun 2018, at 9:54, David Sterba wrote: > On Mon, Jun 25, 2018 at 06:45:32AM -0700, Chris Mason wrote: >> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c >> index 193f933..38403aa 100644 >> --- a/fs/btrfs/inode.c >> +++ b/fs/btrfs/inode.c >>

Re: [PATCH RFC 0/2] Btrfs: fix file data corruptions due to lost dirty bits

On 25 Jun 2018, at 7:10, David Sterba wrote: On Fri, Jun 22, 2018 at 05:25:54PM -0400, Chris Mason wrote: The bug came here: commit a528a24150870c5c16cbbbec69dba7e992b08456 Author: Souptick Joarder Date: Wed Jun 6 19:54:44 2018 +0530 btrfs: change return type of btrfs_page_mkwrite

[PATCH] Btrfs: fix regression in btrfs_page_mkwrite() from vm_fault_t conversion

ARNING in btrfs_destroy_inode() WARN_ON(BTRFS_I(inode)->block_rsv.size); The fix used here is to use ret instead of ret2 in our check for success. Fixes: a528a2415087 (btrfs: change return type of btrfs_page_mkwrite to vm_fault_t) Signed-off-by: Chris Mason --- fs/btrfs/inode.c | 3 ++

Re: [PATCH RFC 0/2] Btrfs: fix file data corruptions due to lost dirty bits

On 20 Jun 2018, at 16:24, David Sterba wrote: On Wed, Jun 20, 2018 at 03:48:08PM -0400, Chris Mason wrote: generic/095 [18:07:03][ 3769.317862] run fstests generic/095 at 2018-06-20 18:07:03 Hmpf, I pass both 095 and 208 here. [ 3774.849685] BTRFS: device fsid 3acffad9-28e5

Re: [RFC PATCH] btrfs: Remove V0 extent support

On 21 Jun 2018, at 5:22, David Sterba wrote: On Thu, Jun 21, 2018 at 09:45:00AM +0300, Nikolay Borisov wrote: The v0 compat code was introduced in commit 5d4f98a28c7d ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9 years ago, which was merged in 2.6.31. This means that

Re: [PATCH RFC 0/2] Btrfs: fix file data corruptions due to lost dirty bits

On 20 Jun 2018, at 15:33, David Sterba wrote: On Wed, Jun 20, 2018 at 07:56:10AM -0700, Chris Mason wrote: We've been hunting the root cause of data crc errors here at FB for a while. We'd find one or two corrupted files, usually displaying crc errors without any corresponding IO errors

Re: [PATCH RFC 0/2] Btrfs: fix file data corruptions due to lost dirty bits

On 20 Jun 2018, at 15:33, David Sterba wrote: On Wed, Jun 20, 2018 at 07:56:10AM -0700, Chris Mason wrote: We've been hunting the root cause of data crc errors here at FB for a while. We'd find one or two corrupted files, usually displaying crc errors without any corresponding IO errors

[PATCH RFC 0/2] Btrfs: fix file data corruptions due to lost dirty bits

We've been hunting the root cause of data crc errors here at FB for a while. We'd find one or two corrupted files, usually displaying crc errors without any corresponding IO errors from the storage. The bug was rare enough that we'd need to watch a large number of machines for a few days just to

[PATCH 2/2] Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker

eep the page dirty while we're waiting for the fixup worker to get to work. This also makes sure the error handling in btrfs_writepage_fixup_worker does the right thing with dirty bits when we run out of space. Signed-off-by: Chris Mason --- fs/btrfs/inode.c |

[PATCH 1/2] Btrfs: don't clean dirty pages during buffered writes

been pending writeback. We don't actually need to clean the pages. All of the other locking in place makes sure we don't start IO on the pages, so we can just leave them dirty for the duration of the write. Fixes: 73d59314e6ed (the original btrfs merge) Signed-off-by: Chris Mason --- fs/btrfs

Re: [LKP] [lkp-robot] [mm] 9092c71bb7: blogbench.write_score -12.3% regression

On 19 Jun 2018, at 23:51, Huang, Ying wrote: "Huang, Ying" writes: Hi, Josef, Do you have time to take a look at the regression? kernel test robot writes: Greeting, FYI, we noticed a -12.3% regression of blogbench.write_score and a +9.6% improvement of blogbench.read_score due to

Re: [Bug 199931] New: systemd/rtorrent file data corruption when using echo 3 >/proc/sys/vm/drop_caches

On 6 Jun 2018, at 9:38, Liu Bo wrote: On Wed, Jun 6, 2018 at 8:18 AM, Chris Mason wrote: On 5 Jun 2018, at 16:03, Andrew Morton wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 05 Jun 2018 18:01:36 + bugzilla-dae

Re: [Bug 199931] New: systemd/rtorrent file data corruption when using echo 3 >/proc/sys/vm/drop_caches

On 5 Jun 2018, at 16:03, Andrew Morton wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 05 Jun 2018 18:01:36 + bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=199931

Re: [PATCH] Btrfs: implement unlocked buffered write

On 24 May 2018, at 4:46, robbieko wrote: Chris Mason 於 2018-05-23 23:56 寫到: On 23 May 2018, at 3:26, robbieko wrote: But we're not avoiding the inode lock completely, we're just dropping it for the expensive parts of writing to the file. A quick guess about what the expensive parts

Re: [PATCH] Btrfs: implement unlocked buffered write

On 23 May 2018, at 2:37, Christoph Hellwig wrote: On Tue, May 22, 2018 at 02:31:36PM -0400, Chris Mason wrote: And what protects two writes from interleaving their results now? page locks...ish, we at least won't have results interleaved in a single page. For btrfs it'll actually

Re: [PATCH] Btrfs: implement unlocked buffered write

On 23 May 2018, at 3:26, robbieko wrote: Chris Mason 於 2018-05-23 02:31 寫到: On 22 May 2018, at 14:08, Christoph Hellwig wrote: On Wed, May 16, 2018 at 11:52:37AM +0800, robbieko wrote: From: Robbie Ko <robbi...@synology.com> This idea is from direct io. By this patch, we ca

Re: [PATCH] Btrfs: implement unlocked buffered write

On 22 May 2018, at 14:08, Christoph Hellwig wrote: On Wed, May 16, 2018 at 11:52:37AM +0800, robbieko wrote: From: Robbie Ko This idea is from direct io. By this patch, we can make the buffered write parallel, and improve the performance and latency. But because we

Re: verify key failure

On 14 May 2018, at 10:35, Liu Bo wrote: Hi, I got another warning of verify_level_key by running btrfs/124 in a loop, I'm testing against 4.17-rc3. Not sure if it's false positive. How long does this take to trigger? -chris -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 1/2 V2] hoist BTRFS_IOC_[SG]ET_FSLABEL to vfs

On 11 May 2018, at 10:10, David Sterba wrote: On Thu, May 10, 2018 at 08:16:09PM +0100, Al Viro wrote: On Thu, May 10, 2018 at 01:13:57PM -0500, Eric Sandeen wrote: Move the btrfs label ioctls up to the vfs for general use. This retains 256 chars as the maximum size through the interface,

Re: metadata_ratio mount option?

On 7 May 2018, at 12:16, Martin Svec wrote: Hello Chris, Dne 7.5.2018 v 16:49 Chris Mason napsal(a): On 7 May 2018, at 7:40, Martin Svec wrote: Hi, According to man btrfs [1], I assume that metadata_ratio=1 mount option should force allocation of one metadata chunk after every allocated

Re: metadata_ratio mount option?

On 7 May 2018, at 7:40, Martin Svec wrote: Hi, According to man btrfs [1], I assume that metadata_ratio=1 mount option should force allocation of one metadata chunk after every allocated data chunk. However, when I set this option and start filling btrfs with "dd if=/dev/zero

Re: Inconsistent behavior of fsync in btrfs

On 29 Apr 2018, at 18:16, Theodore Y. Ts'o wrote: On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote: In the spirit of clarifying fsync behavior, we have one more case where we'd like to find out what should be expected. Consider this: Mkdir A Creat A/bar Fsync A/bar Rename

Re: Inconsistent behavior of fsync in btrfs

On 27 Apr 2018, at 10:07, David Sterba wrote: On Thu, Apr 26, 2018 at 07:59:23PM -0500, Jayashree Mohan wrote: Thanks for the response. We are using a tool we developed called CrashMonkey[1] to run crash consistency tests and generate the bug reports above. We'd be happy to guide you through

Re: Inconsistent behavior of fsync in btrfs

On 26 Apr 2018, at 18:59, Jayashree Mohan wrote: Hi Chris, Thanks for the response. We are using a tool we developed called CrashMonkey[1] to run crash consistency tests and generate the bug reports above. We'd be happy to guide you through setting up CrashMonkey and getting these bugs

Re: Inconsistent behavior of fsync in btrfs

On 24 Apr 2018, at 20:35, Jayashree Mohan wrote: Hi, While investigating crash consistency bugs on btrfs, we came across workloads that demonstrate inconsistent behavior of fsync. Consider the following workload where fsync on the directory did not persist it. Only file B/foo gets

Re: Periodic frame losses when recording to btrfs volume with OBS

On 01/22/2018 04:17 PM, Sebastian Ochmann wrote: > Hello, > > I attached to the ffmpeg-mux process for a little while and pasted the > result here: > >

Re: Periodic frame losses when recording to btrfs volume with OBS

On 01/22/2018 01:33 PM, Sebastian Ochmann wrote: [ skipping to the traces ;) ] 2866 ffmpeg-mux D [] btrfs_start_ordered_extent+0x101/0x130 [btrfs] [] lock_and_cleanup_extent_if_need+0x340/0x380 [btrfs] [] __btrfs_buffered_write+0x261/0x740 [btrfs] [] btrfs_file_write_iter+0x20f/0x650 [btrfs]

Re: Periodic frame losses when recording to btrfs volume with OBS

On 01/20/2018 05:47 AM, Sebastian Ochmann wrote: Hello, I would like to describe a real-world use case where btrfs does not perform well for me. I'm recording 60 fps, larger-than-1080p video using OBS Studio [1] where it is important that the video stream is encoded and written out to disk

Re: Btrfs allow compression on NoDataCow files? (AFAIK Not, but it does)

On 12/20/2017 03:59 PM, Timofey Titovets wrote: How reproduce: touch test_file chattr +C test_file dd if=/dev/zero of=test_file bs=1M count=1 btrfs fi def -vrczlib test_file filefrag -v test_file test_file Filesystem type is: 9123683e File size of test_file is 1048576 (256 blocks of 4096 bytes)

[PATCH] btrfs: fix refcount_t usage when deleting btrfs_delayed_nodes

also changes __btrfs_release_delayed_node() to remove the extra check for zero refcounts before radix tree deletion. btrfs_get_delayed_node() was the only path that was allowing refcounts to go from zero to one. Signed-off-by: Chris Mason <c...@fb.com> Fixes: 6de5f18e7b0da cc: <sta...@vger.kernel.org&

Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

On 11/30/2017 12:23 PM, David Sterba wrote: On Wed, Nov 29, 2017 at 01:38:26PM -0500, Chris Mason wrote: On 11/29/2017 12:05 PM, Tejun Heo wrote: On Wed, Nov 29, 2017 at 09:03:30AM -0800, Tejun Heo wrote: Hello, On Wed, Nov 29, 2017 at 05:56:08PM +0100, Jan Kara wrote: What has happened

Re: [PATCHSET v2] cgroup, writeback, btrfs: make sure btrfs issues metadata IOs from the root cgroup

On 11/29/2017 12:05 PM, Tejun Heo wrote: On Wed, Nov 29, 2017 at 09:03:30AM -0800, Tejun Heo wrote: Hello, On Wed, Nov 29, 2017 at 05:56:08PM +0100, Jan Kara wrote: What has happened with this patch set? No idea. cc'ing Chris directly. Chris, if the patchset looks good, can you please

Re: [PATCH] btrfs: fix deadlock when writing out space cache

On 11/16/2017 03:09 AM, Nikolay Borisov wrote: On 15.11.2017 23:20, Josef Bacik wrote: From: Josef Bacik If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity ensues.

Re: [PATCH] btrfs: fix deadlock when writing out space cache

On 11/15/2017 06:46 PM, Liu Bo wrote: On Wed, Nov 15, 2017 at 04:20:52PM -0500, Josef Bacik wrote: From: Josef Bacik If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity

[GIT PULL v2] zstd support (lib, btrfs, squashfs, nocrypto)

Hi Linus, Nick Terrell's patch series to add zstd support to the kernel has been floating around for a while. After talking with Dave Sterba, Herbert and Phillip, we decided to send the whole thing in as one pull request. Herbert had asked about the crypto patch when we discussed the pull, but

Re: [GIT PULL] zstd support (lib, btrfs, squashfs)

On Sat, Sep 09, 2017 at 09:35:59AM +0800, Herbert Xu wrote: On Fri, Sep 08, 2017 at 03:33:05PM -0400, Chris Mason wrote: crypto/Kconfig |9 + crypto/Makefile|1 + crypto/testmgr.c | 10 + crypto/testmgr.h | 71 + crypto/zstd.c

Re: [GIT PULL] zstd support (lib, btrfs, squashfs)

On 09/08/2017 03:33 PM, Chris Mason wrote: Hi Linus, Nick Terrell's patch series to add zstd support to the kernel has been floating around for a while. After talking with Dave Sterba, Herbert and Phillip, we decided to send the whole thing in as one pull request. I have it in my zstd

[GIT PULL] zstd support (lib, btrfs, squashfs)

Hi Linus, Nick Terrell's patch series to add zstd support to the kernel has been floating around for a while. After talking with Dave Sterba, Herbert and Phillip, we decided to send the whole thing in as one pull request. I have it in my zstd branch:

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Mon, Aug 14, 2017 at 09:54:48PM +0200, Christoph Anton Mitterer wrote: On Mon, 2017-08-14 at 11:53 -0400, Austin S. Hemmelgarn wrote: Quite a few applications actually _do_ have some degree of secondary  verification or protection from a crash.  Go look at almost any database  software.

Re: [PATCH stable v4.12 backport] Btrfs: fix early ENOSPC due to delalloc

On 08/11/2017 10:44 AM, Chris Mason wrote: Hmpf, forgot to put the sha in Linus' tree: 17024ad0a0fdfcfe53043afb969b813d3e020c21 And Nikolay just reminded me this is already in Greg's queue. Whoops. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" i

Re: [PATCH stable v4.12 backport] Btrfs: fix early ENOSPC due to delalloc

Hmpf, forgot to put the sha in Linus' tree: 17024ad0a0fdfcfe53043afb969b813d3e020c21 -chris On 08/11/2017 10:41 AM, Chris Mason wrote: From: Omar Sandoval <osan...@fb.com> If a lot of metadata is reserved for outstanding delayed allocations, we rely on shrink_delalloc() to reclaim me

Re: FAILED: patch "[PATCH] Btrfs: fix early ENOSPC due to delalloc" failed to apply to 4.12-stable tree

On 08/04/2017 03:29 PM, Christoph Anton Mitterer wrote: > Hey. > > Could someone of the devs put some attention on this...? > > Thanks, > Chris :-) Done, you can also grab it here:

[PATCH stable v4.12 backport] Btrfs: fix early ENOSPC due to delalloc

by: David Sterba <dste...@suse.com> Signed-off-by: Chris Mason <c...@fb.com> --- fs/btrfs/extent-tree.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 33d979e9..83eecd3 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/ex

Re: [PATCH v5 2/5] lib: Add zstd modules

On 08/10/2017 03:25 PM, Hugo Mills wrote: On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: On 08/10/2017 04:30 AM, Eric Biggers wrote: Theses benchmarks are misleading because they compress the whole file as a single stream without resetting the dictionary, which isn't how data

Re: [PATCH v5 2/5] lib: Add zstd modules

On 08/10/2017 03:00 PM, Eric Biggers wrote: On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: On 08/10/2017 04:30 AM, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: The memory reported is the amount of memory the compressor requests. | Method

Re: [PATCH v5 2/5] lib: Add zstd modules

On 08/10/2017 04:30 AM, Eric Biggers wrote: On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: The memory reported is the amount of memory the compressor requests. | Method | Size (B) | Time (s) | Ratio | MB/s| Adj MB/s | Mem (MB) |

Re: [PATCH] Btrfs: avoid unnecessarily locking inode when clearing a range

On 08/03/2017 11:25 AM, Wang Shilong wrote: On Thu, Aug 3, 2017 at 11:00 PM, Chris Mason <c...@fb.com> wrote: On 07/27/2017 02:52 PM, fdman...@kernel.org wrote: From: Filipe Manana <fdman...@suse.com> If the range being cleared was not marked for defrag and we are not ab

Re: [PATCH] btrfs: Move skip checksum check from btrfs_submit_direct to __btrfs_submit_dio_bio

function actually has all the necessary context to figure out whether to skip the check or not, so let's move the check closer to where it's being consumed. No functional changes. I like it, thanks. Reviewed-by: Chris Mason <c...@fb.com> -chris -- To unsubscribe from this list: send th

Re: [PATCH] Btrfs: avoid unnecessarily locking inode when clearing a range

how the inode lock is required here. Reviewed-by: Chris Mason <c...@fb.com> -chris --- fs/btrfs/inode.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index eb495e956d53..51c45c0a8553 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inod

Re: [PATCH 00/14 RFC] Btrfs: Add journal for raid5/6 writes

On 08/01/2017 01:39 PM, Austin S. Hemmelgarn wrote: On 2017-08-01 13:25, Roman Mamedov wrote: On Tue, 1 Aug 2017 10:14:23 -0600 Liu Bo wrote: This aims to fix write hole issue on btrfs raid5/6 setup by adding a separate disk as a journal (aka raid5/6 log), so that

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On 08/02/2017 04:38 AM, Brendan Hide wrote: The title seems alarmist to me - and I suspect it is going to be misconstrued. :-/ Supporting any filesystem is a huge amount of work. I don't have a problem with Redhat or any distro picking and choosing the projects they want to support. At

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

On 07/24/2017 03:06 PM, Austin S. Hemmelgarn wrote: On 2017-07-24 14:53, Chris Mason wrote: On 07/24/2017 02:41 PM, David Sterba wrote: would it be ok for you to keep ssd_working as before? I'd really like to get this patch merged soon because "do not use ssd mode for ssd" h

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

On 07/24/2017 02:41 PM, David Sterba wrote: On Mon, Jul 24, 2017 at 02:01:07PM -0400, Chris Mason wrote: On 07/24/2017 10:25 AM, David Sterba wrote: Thanks for the extensive historical summary, this change really deserves it. Decoupling the assumptions about the device's block management

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

On 07/24/2017 10:25 AM, David Sterba wrote: Thanks for the extensive historical summary, this change really deserves it. Decoupling the assumptions about the device's block management is really a good thing, mount option 'ssd' should mean that the device just has cheap seeks. Moving the the

Re: [PULL] Btrfs for 4.13, part 1

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 incremental work on the GFP_NOFS (mis)use removal. All patches have been in for-next

[PATCH v2] btrfs: fix integer overflow in calc_reclaim_items_nr

64->32 bit overflows. This switches calc_reclaim_items_nr() to return a u64 and changes everyone that uses the results of that math to u64 as well. Reported-by: Dave Jones <da...@codemonkey.org.uk> Fixes: 70e7af2 ("Btrfs: fix delalloc accounting leak caused by u32 overflow"

Re: [PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr

On 06/23/2017 11:29 AM, Holger Hoffstätte wrote: On 06/23/17 16:32, Chris Mason wrote: [..] -static inline int calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, +static inline u64 calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, u64 to_reclaim

[PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr

64->32 bit overflows. This switches calc_reclaim_items_nr() to return a u64 and changes everyone that uses the results of that math to u64 as well. Reported-by: Dave Jones <da...@codemonkey.org.uk> Fixes: 70e7af244f24c94604ef6eca32ad297632018583 Signed-off-by: Chris Mason <c...@fb.com

Re: [PATCH 1/2] btrfs: account for pinned bytes and bytes_may_use in should_alloc_chunk

On 06/21/2017 05:08 PM, Jeff Mahoney wrote: On 6/21/17 4:31 PM, Chris Mason wrote: On 06/21/2017 04:14 PM, Jeff Mahoney wrote: On 6/14/17 11:44 AM, je...@suse.com wrote: From: Jeff Mahoney <je...@suse.com> In a heavy write scenario, we can end up with a large number of pinned

Re: [PATCH 1/2] btrfs: account for pinned bytes and bytes_may_use in should_alloc_chunk

On 06/21/2017 04:14 PM, Jeff Mahoney wrote: On 6/14/17 11:44 AM, je...@suse.com wrote: From: Jeff Mahoney In a heavy write scenario, we can end up with a large number of pinned bytes. This can translate into (very) premature ENOSPC because pinned bytes must be accounted for

Re: btrfs_wait_ordered_roots warning triggered

On 06/21/2017 11:16 AM, Dave Jones wrote: WARNING: CPU: 2 PID: 7153 at fs/btrfs/ordered-data.c:753 btrfs_wait_ordered_roots+0x1a3/0x220 CPU: 2 PID: 7153 Comm: kworker/u8:7 Not tainted 4.12.0-rc6-think+ #4 Workqueue: events_unbound btrfs_async_reclaim_metadata_space task: 8804f08d5380

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.12 branch has some fixes that Dave Sterba collected: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.12 We've been hitting an early enospc problem on production machines that Omar tracked down to an old int->u64 mistake. I waited a bit

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: btrfs list corruption and soft lockups while testing writeback error handling

On 05/11/2017 03:52 PM, Jeff Layton wrote: On Thu, 2017-05-11 at 07:13 -0400, Jeff Layton wrote: I finally got my writeback error handling test to work on btrfs (thanks, Chris!), by making the filesystem stripe the data and mirror the metadata across two devices. The test passes now, but on one

Re: [GIT PULL] Btrfs

On 05/09/2017 01:56 PM, Chris Mason wrote: > Hi Linus, > > My for-linus-4.12 branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git > for-linus-4.12 I hit send too soon, sorry. There's a trivial conflict with our WARN_ON fix that went in

[GIT PULL] Btrfs

) btrfs: No need to check !(flags & MS_RDONLY) twice (+1/-2) Chris Mason (1) commits (+2/-2): btrfs: fix the gfp_mask for the reada_zones radix tree Adam Borowski (1) commits (+9/-3): btrfs: fix a bogus warning when converting only data or metadata Deepa Dinamani (1) commits (+

Re: [PATCH] btrfs: always write superblocks synchronously

On 05/03/2017 04:36 AM, Jan Kara wrote: On Tue 02-05-17 09:28:13, Davidlohr Bueso wrote: Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as synchronous" removed REQ_SYNC flag from WRITE_FUA implementation. Since REQ_FUA and REQ_FLUSH flags are stripped from submitted IO when the

[GIT PULL] Btrfs

Hi Linus, We have one more for btrfs: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 This is dropping a new WARN_ON from rc1 that ended up making more noise than we really want. The larger fix for the underflow got delayed a bit and it's better for now

Re: [GIT PULL] Btrfs bug fixes for 4.12

On 04/26/2017 01:52 PM, fdman...@kernel.org wrote: From: Filipe Manana Hi Chris, Please consider the following changes for the 4.12 merge window. These are all bug fixes and nothing particularly outstanding compared to changes for past merge windows. Thanks. The following

Re: [PULL] Btrfs, updates for 4.12

On 04/26/2017 11:06 AM, Filipe Manana wrote: > Hi, > > Did you actually ran xfstests with those readahead patches to > preallocate radix tree nodes? > > With those 2 patches applied (Chris' for-linus.4,12 branch) this > breaks things and many btrfs specific tests (at least, since I can't > get

Re: [PULL] Btrfs, updates for 4.12

On 04/26/2017 11:06 AM, Filipe Manana wrote: Hi, Did you actually ran xfstests with those readahead patches to preallocate radix tree nodes? With those 2 patches applied (Chris' for-linus.4,12 branch) this breaks things and many btrfs specific tests (at least, since I can't get pass them)

Re: [PULL] Btrfs, qgroup message level adjustment, for 4.11-rc8

On 04/25/2017 10:21 AM, David Sterba wrote: On Wed, Apr 19, 2017 at 12:51:03PM +0200, David Sterba wrote: Hi, a single-patch pull request, the qgroup use can trigger an underflow warning frequently. The warning is for debugging and should not be in the final release of 4.11 as we won't be able

[GIT PULL] Btrfs

Hi Linus Dave Sterba collected a few more fixes for the last rc: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 These aren't marked for stable, but I'm putting them in with a batch were testing/sending by hand for this release. Liu Bo (3) commits

[GIT PULL] Btrfs

Hi Linus, We have 3 small fixes queued up in my for-linus-4.11 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Goldwyn Rodrigues (1) commits (+7/-7): btrfs: Change qgroup_meta_rsv to 64bit Dan Carpenter (1) commits (+6/-1): Btrfs: fix an

[GIT PULL] Btrfs

Hi Linus We have a small set of fixes for the next RC: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Zygo tracked down a very old bug with inline compressed extents. I didn't tag this one for stable because I want to do individual tested backports. It's

Re: [PULL] Btrfs updates for 4.11-rc2

On 03/09/2017 08:55 AM, David Sterba wrote: Hi, there's a regression fix for the assertion failure reported by Dave Jones, the rest of patches are minor updates. Please pull, thanks. The following changes since commit e9f467d028cd7d8bee2a4d6c4fb806caf8cd580b: Merge branch

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

On 03/10/2017 01:56 PM, Zygo Blaxell wrote: On Fri, Mar 10, 2017 at 11:19:24AM -0500, Chris Mason wrote: On 03/09/2017 11:41 PM, Zygo Blaxell wrote: On Thu, Mar 09, 2017 at 10:39:49AM -0500, Chris Mason wrote: On 03/08/2017 09:12 PM, Zygo Blaxell wrote: This is a story about 4 distinct

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

On 03/09/2017 11:41 PM, Zygo Blaxell wrote: On Thu, Mar 09, 2017 at 10:39:49AM -0500, Chris Mason wrote: On 03/08/2017 09:12 PM, Zygo Blaxell wrote: This is a story about 4 distinct (and very old) btrfs bugs. Really great write up. [ ... ] diff --git a/fs/btrfs/inode.c b/fs/btrfs

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

On 03/08/2017 09:12 PM, Zygo Blaxell wrote: This is a story about 4 distinct (and very old) btrfs bugs. Really great write up. [ ... ] diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 25ac2cf..4d41a31 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -6805,6 +6805,12 @@

Re: [PATCH 0/9 PULL REQUEST] Qgroup fixes for 4.11

On 03/06/2017 11:44 AM, David Sterba wrote: On Mon, Mar 06, 2017 at 04:08:41PM +0800, Qu Wenruo wrote: Any response? These patches are already here for at least 2 kernel releases. And are all bug fixes, and fix bugs that are already reported. I didn't see any reason why it should be delayed

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.11 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Has Btrfs round two. These are mostly a continuation of Dave Sterba's collection of cleanups, but Filipe also has some bug fixes and performance improvements. Nikolay

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.11 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Has a series of fixes and cleanups that Dave Sterba has been collecting: There is a pretty big variety here, cleaning up internal APIs and fixing corner cases. David Sterba

Re: [GIT PULL] Btrfs bug fixes and improvements for 4.11 (2nd retry)

On Fri, Feb 24, 2017 at 03:25:09AM +, fdman...@kernel.org wrote: From: Filipe Manana Hi Chris, since my previous pull request (sent timely) was either missed or not pulled for some reason I'm not aware of, here I send it again (with one more patch included). The

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.10 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.10 Has two last minute fixes. The highest priority here is a regression fix for the decompression code, but we also fixed up a problem with the 32 bit compat ioctls. The

Re: [PATCH v2] Btrfs: fix btrfs_decompress_buf2page()

On Fri, Feb 10, 2017 at 08:12:35PM -0800, Pat Erley wrote: On 02/10/17 15:03, Omar Sandoval wrote: From: Omar Sandoval If btrfs_decompress_buf2page() is handed a bio with its page in the middle of the working buffer, then we adjust the offset into the working buffer. After

Re: [PULL] Fix ioctls on 32bit/64bit userspace/kernel, for 4.10

On Wed, Feb 08, 2017 at 05:51:28PM +0100, David Sterba wrote: Hi, could you please merge this single-patch pull request, for 4.10 still? There are quite a few patches on top of v4.10-rc7 so this IMHO does not look like look too bad even late in the release cycle. Though it's a fix for an

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.10 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.10 Has some fixes that we've collected from the list. We still have one more pending to nail down a regression in lzo compression, but I wanted to get this batch out the door.

Re: [PATCH v2 0/3] Btrfs: disable xattr operations on subvolume directories

On 01/25/2017 08:06 PM, Omar Sandoval wrote: From: Omar Sandoval This series is based on v4.10-rc4. It should probably go in for v4.10 and to stable for v4.9.x. Thanks Omar, I've got this queued on top of Dave's pull. -chris -- To unsubscribe from this list: send the line

  1   2   3   4   5   6   7   8   9   10   >