On 10 May 2019, at 9:45, Chris Mason wrote:
> On 10 May 2019, at 7:15, Johannes Thumshirn wrote:
>
>> Currently btrfs_csum_data() relied on the crc32c() wrapper around the
>> crypto
>> framework for calculating the CRCs.
>>
>> As we have our own crypto_sh
On 13 May 2019, at 3:17, Johannes Thumshirn wrote:
> On Fri, May 10, 2019 at 01:54:30PM +0000, Chris Mason wrote:
>> Looking at the callers of btrfs_csum_final() and btrfs_csum_data(),
>> lets
>> just pass the shash_desc from the callers. That way you don't have
&
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
of=dummyfile.da
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
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,
wh
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 li
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
can not update isize witho
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
This idea is from direct io. By this patch, we can make the
buffered
write parallel
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 a
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
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
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
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 commi
ny modifications that had 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
to keep
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
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 c
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
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
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 the
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
ING 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 ++
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 to
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
>>
n 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/btr
On 10/26/2016 08:00 PM, Jens Axboe wrote:
> On 10/26/2016 05:47 PM, Dave Jones wrote:
>> On Wed, Oct 26, 2016 at 07:38:08PM -0400, Chris Mason wrote:
>>
>> > >-hctx->queued++;
>> > >-data->hctx = hctx;
>> > >-
c_log().
Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4
Reported-by: Dave Jones
cc: sta...@vger.kernel.org # 3.15+
Signed-off-by: Chris Mason
---
fs/btrfs/tree-log.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 688df71..4b1c0
'm no longer able to trigger problems.
Filipe is fixing a difficult old bug between snapshots, balance and
send. Dave is cooking a few more for the next rc, but these are tested
and ready:
Chris Mason (1) commits (+6/-14):
btrfs: fix races on root_log_ctx lists
Filipe Manana (1) commi
On Mon, Oct 31, 2016 at 08:36:44AM -0700, Christoph Hellwig wrote:
On Sat, Oct 29, 2016 at 04:08:25PM +0800, Ming Lei wrote:
There are lots of direct access to .bi_vcnt & .bi_io_vec
of bio, and it isn't ready to support multipage bvecs
for BTRFS, so set NO_MP for these request queues.
For one
On Mon, Oct 31, 2016 at 12:35:16PM -0700, Linus Torvalds wrote:
On Mon, Oct 31, 2016 at 11:55 AM, Dave Jones wrote:
BUG: Bad page state in process kworker/u8:12 pfn:4e0e39
page:ea0013838e40 count:0 mapcount:0 mapping:8804a20310e0 index:0x100c
flags: 0x400c(referenced|uptod
On Tue, Nov 01, 2016 at 02:02:25PM +0100, David Sterba wrote:
Hi,
please pull the following assorted small fixes to 4.9, thanks. The branch is
"rc3" as it was meant for rc3 but I did not get to sending the pull request,
and I don't want to recreate the branch just because of a slightly wrong
nam
Hi Linus,
My for-linus-4.9 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.9
Has some fixes that Dave Sterba collected. We held off on these last
week because I was focused on the memory corruption testing.
I had asked you about pulling this directly f
On 11/08/2016 09:59 AM, Dave Jones wrote:
On Sun, Nov 06, 2016 at 11:55:39AM -0500, Dave Jones wrote:
>
>
> On Mon, Oct 31, 2016 at 01:44:55PM -0600, Chris Mason wrote:
> > On Mon, Oct 31, 2016 at 12:35:16PM -0700, Linus Torvalds wrote:
> > >On Mon, Oct 31, 2016
On 11/10/2016 09:35 AM, Dave Jones wrote:
On Tue, Nov 08, 2016 at 10:08:04AM -0500, Chris Mason wrote:
> > And another new one:
> >
> > kernel BUG at fs/btrfs/ctree.c:3172!
> >
> > Call Trace:
> > [] __btrfs_drop_extents+0xb00/0xe30 [btrfs]
>
>
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.
Lo
On 11/14/2016 02:06 PM, Josef Bacik wrote:
In order to do hole punching we have a block reserve to hold the reservation we
need to drop the extents in our range. Since we could end up dropping a lot of
extents we set rsv->failfast so we can just loop around again and drop the
remaining of the ra
On 11/17/2016 12:39 AM, Chris Cui wrote:
We have just encountered the same bug on 4.9.0-rc2. Any solution now?
kernel BUG at fs/btrfs/ctree.c:3172!
invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 0 PID: 22702 Comm: trinity-c40 Not tainted 4.9.0-rc4-think+ #1
task: 8804ffde37c0 t
On 11/16/2016 11:10 AM, David Sterba wrote:
On Mon, Nov 14, 2016 at 09:55:34AM +0800, Qu Wenruo wrote:
At 11/12/2016 04:22 AM, Liu Bo wrote:
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
On 11/08/2016 04:30 AM, Wang Xiaoguang wrote:
The current limit of number of asynchronous delalloc pages is (10 * SZ_1M).
For 4K page, the total ram bytes would be 40G, very big value, I think in
most cases, this limit will not work, here I set limit of the number of
asynchronous delalloc pages t
On 11/22/2016 04:20 AM, Wang Xiaoguang wrote:
hello,
On 11/22/2016 12:39 AM, David Sterba wrote:
On Tue, Nov 08, 2016 at 05:30:58PM +0800, Wang Xiaoguang wrote:
The current limit of number of asynchronous delalloc pages is (10 *
SZ_1M).
For 4K page, the total ram bytes would be 40G, very big v
On 11/21/2016 03:50 AM, Qu Wenruo wrote:
In the following situation, scrub will calculate wrong parity to
overwrite correct one:
RAID5 full stripe:
Before
| Dev 1 | Dev 2 | Dev 3 |
| Data stripe 1 | Data stripe 2 | Parity Stripe |
HOLES mode when data is not flushed.
However, even if data has been flushed, we can still have trouble
in updating disk isize since we updated disk isize to 'start' of
the last evicted extent.
Also add a ASSERT for better catching (for developers only).
Signed-off-by: Liu Bo
Thanks
On 10/24/2016 11:43 AM, David Sterba wrote:
Hi Josef,
are you fine with V2?
On Thu, Oct 13, 2016 at 05:31:25PM +0800, Wang Xiaoguang wrote:
Since commit b02441999efcc6152b87cd58e7970bb7843f76cf, we don't wait all
ordered extents, but I run into some enospc errors when doing large file
create a
nd then go to create a new 8K
extent directly without adjusting @len.
Signed-off-by: Liu Bo
Reviewed-by: Chris Mason
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
On Fri, Nov 25, 2016 at 10:03:25AM +0100, Christian Borntraeger wrote:
FWIW, I still see the lockdep splat in btrfs in 4.9-rc5+
Filipe reworked the code to avoid taking the same lock twice. As far as
I can tell, this just needs some annotation.
-chris
--
To unsubscribe from this list: send
On 11/22/2016 07:26 PM, Qu Wenruo wrote:
We're changing which pages we kmap() but not which ones we kunmap(). Can
you please update the kunmap loop to use this pointers array? Also it
looks like this kmap is never unmapped.
Oh I forget that.
I'll update it soon.
Thanks!
This reminds me
On 11/25/2016 03:07 AM, Christoph Hellwig wrote:
Any chance to get someone look at this or the next bug report?
I've been trying to reproduce, but haven't yet. This test does hit the
CPU hard, which PREEMPT setting are you using?
-chris
On Mon, Nov 14, 2016 at 04:35:29AM -0800, Christoph
On 12/04/2016 04:28 PM, Chris Murphy wrote:
4.8.11-300.fc25.x86_64
I'm currently doing a btrfs send/receive and I'm seeing a rather large
hit for crc32c, bigger than aes-ni (the volume is on dm crypt), using
perf top.
14.03% btrfs[.] __crc32c_le
10.50%
On 12/05/2016 08:34 PM, Chris Murphy wrote:
On Mon, Dec 5, 2016 at 8:46 AM, Chris Mason wrote:
On 12/04/2016 04:28 PM, Chris Murphy wrote:
4.8.11-300.fc25.x86_64
I'm currently doing a btrfs send/receive and I'm seeing a rather large
hit for crc32c, bigger than aes-ni (the volum
On 12/07/2016 04:45 PM, Liu Bo wrote:
This has implemented DAX support for btrfs with nocow and single-device.
DAX is developed for block devices that are memory-like in order to avoid
double buffer in both page cache and the storage, so DAX can performs reads and
writes directly to the storag
On 12/09/2016 12:13 AM, Dave Chinner wrote:
On Wed, Dec 07, 2016 at 01:45:08PM -0800, Liu Bo wrote:
Since I haven't figure out how to map multiple devices to userspace without
pagecache, this DAX support is only for single-device, and I don't think
DAX(Direct Access) can work with cow, this is
On 12/12/2016 03:35 PM, Maxim Patlasov wrote:
On 12/12/2016 06:54 AM, David Sterba wrote:
As far as we don't have any NO_THRESHOLD users of
btrfs_workqueue_normal_congested for now, I tend to think it's better to
add a descriptive comment and simply return "false" from
btrfs_workqueue_normal_con
ady calculated value in
btrfs_should_throttle_delayed_refs() (+1/-1)
btrfs: add necessary comments about tickets_id (+4/-0)
btrfs: improve delayed refs iterations (+37/-6)
Liu Bo (2) commits (+12/-6):
Btrfs: adjust len of writes if following a preallocated extent (+5/-3)
Btrfs: fi
On 12/16/2016 02:39 AM, Michal Hocko wrote:
[CC linux-mm and btrfs guys]
On Thu 15-12-16 23:57:04, Nils Holland wrote:
[...]
Of course, none of this are workloads that are new / special in any
way - prior to 4.8, I never experienced any issues doing the exact
same things.
Dec 15 19:02:16 teela
On 12/16/2016 02:39 AM, Michal Hocko wrote:
[CC linux-mm and btrfs guys]
On Thu 15-12-16 23:57:04, Nils Holland wrote:
[...]
Of course, none of this are workloads that are new / special in any
way - prior to 4.8, I never experienced any issues doing the exact
same things.
Dec 15 19:02:16 teela
On 12/16/2016 05:14 PM, Michal Hocko wrote:
On Fri 16-12-16 13:15:18, Chris Mason wrote:
On 12/16/2016 02:39 AM, Michal Hocko wrote:
[...]
I believe the right way to go around this is to pursue what I've started
in [1]. I will try to prepare something for testing today for you. Stay
On Wed, Dec 21, 2016 at 12:16:53PM +0100, Michal Hocko wrote:
On Wed 21-12-16 20:00:38, Tetsuo Handa wrote:
One thing to note here, when we are talking about 32b kernel, things
have changed in 4.8 when we moved from the zone based to node based
reclaim (see b2e18757f2c9 ("mm, vmscan: begin recla
On 01/05/2017 10:22 AM, David Sterba wrote:
Hi,
a collection of fixes (lockdep, delayed ref locking, dio). The
btrfs_uuid_tree_iterate return value fix has a visible impact so it's added to
the mix. Please pull.
The following changes since commit 2939e1a86f758b55cdba73e29397dd3d94df13bc:
btr
On 01/06/2017 12:22 PM, Joseph Salisbury wrote:
Hi Luke,
A kernel bug report was opened against Ubuntu [0]. This bug was fixed
by the following commit in v4.7-rc1:
commit 4c63c2454eff996c5e27991221106eb511f7db38
Author: Luke Dashjr
Date: Thu Oct 29 08:22:21 2015 +
btrfs: bugfix:
Hi Linus,
Dave Sterba queued up a few fixes for btrfs. I have them in my
for-linus-4.10 branch:
These are all over the place. The tracepoint part of the pull fixes a
crash and adds a little more information to two tracepoints, while the
rest are good old fashioned fixes.
git://git.kernel.org/p
On Fri, Jan 20, 2017 at 03:42:50PM +0100, David Sterba wrote:
Hi,
a few more fixes, please pull. Thanks.
Great, thanks Dave, rolling tests.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On Mon, Jan 23, 2017 at 06:53:21PM +0100, Christoph Anton Mitterer wrote:
Just wondered... is there any larger known RAID56 deployment? I mean
something with real-world production systems and ideally many different
IO scenarios, failures, pulling disks randomly and perhaps even so
many disks that
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 "unsubscribe linux-
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.
On Fri, Feb 26, 2016 at 10:41:31AM +0500, Roman Mamedov wrote:
> On Wed, 6 Jan 2016 19:00:17 +0800
> Zhao Lei wrote:
>
> > btrfs failed in xfstests btrfs/080 with -o nodatacow.
> >
> > Can be reproduced by following script:
> > DEV=/dev/vdg
> > MNT=/mnt/tmp
> >
> > umount $DEV &>/dev/null
On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> Hi Chris,
>
> On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> > The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
> >
> > Merge branch 'for-next' of
> > git://git.kernel.org/pub/sc
On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote:
> On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
> > This patchset adds btrfs encryption support.
> >
> > Warning:
> > The code is in prototype/experimental stage and is not suitable
> > for the production data yet.
>
>
On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote:
> On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote:
> > We'll definitely move in line with the common API over time. Thanks
> > Anand for starting this!
> >
> > I'd prefer that w
On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/01 11:06 -0500:
> >On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> >>Hi Chris,
> >>
> >>On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@ke
On Wed, Mar 02, 2016 at 09:24:46AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/01 20:11 -0500:
> >On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
> >>
> >>
> >>Chris Mason wrote on 2016/03/01 11:06 -0500:
> >>>On Tue
On Thu, Mar 03, 2016 at 01:28:29PM +0100, Holger Hoffstätte wrote:
>
> Here's an observation that is not a bug (as in data corruption), just
> somewhat odd and unnecessary behaviour. It could be considered a
> performance or scalability bug.
>
> I've noticed that slow slow buffered writes create
Hi Linus,
We've got a fix in my for-linus-4.5 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.5
Filipe nailed down a problem where tree log replay would do some work
that orphan code wasn't expecting to be done yet, leading to BUG_ON.
Filipe Manana (1) c
On Tue, Mar 15, 2016 at 02:50:14PM +0100, David Sterba wrote:
> Hi,
>
> a few more cleanups sent recently and some that I found in my inbox marked but
> not processed. Based on top of current integration. Please pull, thanks.
Thanks Dave, I'll get these pulled in and restart my long stress run.
stop moving forward
too, and the bvec deref is never actually used for anything. But
CONFIG_DEBUG_PAGEALLOC catches it because we're outside our bio.
Signed-off-by: Chris Mason
Reviewed-by: David Sterba
---
fs/btrfs/file-item.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/
On Mon, Mar 21, 2016 at 05:38:44PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If the lower or upper directory of an overlayfs mount belong to a btrfs
> file system and we fsync the file through the overlayfs' merged directory
> we ended up accessing an inode that didn't belong to
On Mon, Mar 21, 2016 at 06:58:08PM +0100, David Sterba wrote:
> On Mon, Mar 21, 2016 at 01:51:07PM -0400, Chris Mason wrote:
> > On Mon, Mar 21, 2016 at 05:38:44PM +, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > If the lower or upper di
in comments.
Satoru Takeuchi (1) commits (+3/-0):
Btrfs: Show a warning message if one of objectid reaches its highest value
Ashish Samant (1) commits (+6/-1):
btrfs: Print Warning only if ENOSPC_DEBUG is enabled
Sudip Mukherjee (1) commits (+1/-1):
btrfs: fix build warning
Chris Mason (1)
On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote:
> On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote:
> >
> > I waited an extra day to send this one out because I hit a crash late
> > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed in the top commit).
>
On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote:
> On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote:
> > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote:
> > >
> > > I waited an extra day to send this one out because I hit a cras
On Tue, Mar 22, 2016 at 09:35:50AM +0800, Qu Wenruo wrote:
> From: Wang Xiaoguang
>
> The basic idea is also calculate hash before compression, and add needed
> members for dedupe to record compressed file extent.
>
> Since dedupe support dedupe_bs larger than 128K, which is the up limit
> of co
On Tue, Mar 22, 2016 at 09:35:35AM +0800, Qu Wenruo wrote:
> Introduce a new tree, dedupe tree to record on-disk dedupe hash.
> As a persist hash storage instead of in-memeory only implement.
>
> Unlike Liu Bo's implement, in this version we won't do hack for
> bytenr -> hash search, but add a new
On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/24 16:58 -0400:
> >Are you storing the entire hash, or just the parts not represented in
> >the key? I'd like to keep the on-disk part as compact as possible for
> >
On Fri, Mar 25, 2016 at 09:44:31AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/24 16:35 -0400:
> >On Tue, Mar 22, 2016 at 09:35:50AM +0800, Qu Wenruo wrote:
> >>From: Wang Xiaoguang
> >>
> >>The basic idea is also calculate hash before c
On Mon, Mar 21, 2016 at 05:52:44PM +, Filipe Manana wrote:
> On Mon, Mar 21, 2016 at 5:51 PM, Chris Mason wrote:
> > On Mon, Mar 21, 2016 at 05:38:44PM +, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> If the lower or upper directory of
On Sat, Mar 26, 2016 at 09:11:53PM +0800, Qu Wenruo wrote:
>
>
> On 03/25/2016 11:11 PM, Chris Mason wrote:
> >On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote:
> >>
> >>
> >>Chris Mason wrote on 2016/03/24 16:58 -0400:
> >>>
trfs filesystems.
>
> This issue has been reported several times by users in the mailing list
> and bugzilla. A test case for xfstests is being submitted as well.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101951
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109791
> Signed-off-by: Filipe Manana
Signed-off-by: Chris Mason
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 30, 2016 at 11:37:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If we rename an inode A (be it a file or a directory), create a new
> inode B with the old name of inode A and under the same parent directory,
> fsync inode B and then power fail, at log tree replay ti
Hi Linus,
My for-linus-4.6 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.6
Has a few fixes Dave Sterba had queued up. These are all pretty small,
but since they were tested I decided against waiting for more:
Alex Lyakas (2) commits (+18/-10):
btr
On Tue, Apr 05, 2016 at 03:36:57PM +0200, Lars Ellenberg wrote:
> blk_check_plugged() will return a pointer
> to an object linked on current->plug->cb_list.
>
> That list may "at any time" be implicitly cleared by
> blk_flush_plug_list()
> flush_plug_callbacks()
> either as a result of blk_finish
Hi Linus
We have some fixes queued up in my for-linus-4.6 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.6
These are bug fixes, including a really old fsync bug, and a few
trace points to help us track down problems in the quota code.
Mark Fasheh (2) co
On Wed, Apr 20, 2016 at 10:02:27AM +0800, Qu Wenruo wrote:
> Hi David,
>
> Any new comment about the ondisk format and ioctl interface?
Hi Qu,
I'm at LSF this week but will dig through again on the way home.
Thanks!
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs
On Wed, Apr 27, 2016 at 02:25:50PM +0200, Christian Borntraeger wrote:
> Folks,
>
> I can sometimes trigger the following bug
>
> [ 244.493534] [ cut here ]
> [ 244.493624] WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261
> btrfs_destroy_inode+0x288/0x2b0 [btrfs]
>
stake every year or so.
Subject: [PATCH] btrfs: fix deadlock in delayed_ref_async_start
"Btrfs: track transid for delayed ref flushing" was deadlocking on
btrfs_attach_transaction because its not safe to call from the async
delayed ref start code. This commit brings back btrfs_join_tran
On Tue, May 10, 2016 at 06:19:20PM -0500, Eric Biggers wrote:
> Hello,
>
> The following warning has been triggering for me since about v4.6-rc3:
>
> WARN_ON(BTRFS_I(inode)->csum_bytes);
>
> On one machine the warning has occurred 657 times since v4.6-rc5. On another
> it
> has occurred
On Tue, May 10, 2016 at 03:19:52PM +0800, Qu Wenruo wrote:
> Hi, Chris, Josef and David,
>
> As merge window for v4.7 is coming, it would be good to hear your ideas
> about the inband dedupe.
>
> We are addressing the ENOSPC problem which Josef pointed out, and we believe
> the final fix patch wo
On Wed, May 11, 2016 at 04:56:56PM +0100, Filipe Manana wrote:
> On Wed, May 11, 2016 at 4:41 PM, Josef Bacik wrote:
> > On 05/09/2016 07:01 AM, fdman...@kernel.org wrote:
> >>
> >> From: Filipe Manana
> >>
> >> When we do a direct IO write against a preallocated extent (fallocate)
> >> that does
On Wed, May 11, 2016 at 09:10:12AM -0700, Josef Bacik wrote:
> On 05/11/2016 09:05 AM, Chris Mason wrote:
> >On Wed, May 11, 2016 at 04:56:56PM +0100, Filipe Manana wrote:
> >>On Wed, May 11, 2016 at 4:41 PM, Josef Bacik wrote:
> >>>On 05/09/2016 07:01
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 uncomm
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 we copy into the b
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 decom
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 following is taken from the
301 - 400 of 2656 matches
Mail list logo
