> On Feb 5, 2021, at 1:58 AM, Boris Burkov wrote:
>
> On Thu, Feb 04, 2021 at 10:13:54PM -0800, Eric Biggers wrote:
>> On Thu, Feb 04, 2021 at 03:21:36PM -0800, Boris Burkov wrote:
>>> This patchset provides support for fsverity in btrfs.
>>
>> Very interested to see this! It generally looks g
> On Feb 5, 2021, at 3:06 AM, Nikolay Borisov wrote:
>
>> +
>> +/*
>> + * drop all the items for this inode with this key_type. Before
>> + * doing a verity enable we cleanup any existing verity items.
>> + *
>> + * This is also used to clean up if a verity enable failed half way
>> + * throug
> On Feb 5, 2021, at 1:39 AM, Eric Biggers wrote:
>
> On Thu, Feb 04, 2021 at 03:21:38PM -0800, Boris Burkov wrote:
>> +/*
>> + * drop all the items for this inode with this key_type. Before
>> + * doing a verity enable we cleanup any existing verity items.
>> + *
>> + * This is also used to c
On 25 Sep 2019, at 8:07, Colin Walters wrote:
> On Wed, Sep 25, 2019, at 3:11 AM, Dave Chinner wrote:
>>
>> We're talking about user data read/write access here, not some
>> special security capability. Access to the data has already been
>> permission checked, so why should the format that the da
On 11 Sep 2019, at 15:55, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> So fix this by not overwriting the return value (ret) with the result
> from flush_write_bio(). We also need to clear the
> EXTENT_BUFFER_WRITEBACK
> bit in case flush_write_bio() returns an error, otherwise it will h
On 11 Jul 2019, at 12:00, Nikolay Borisov wrote:
> On 10.07.19 г. 22:28 ч., Tejun Heo wrote:
>> From: Chris Mason
>>
>> The btrfs writepages function collects a large range of pages flagged
>> for delayed allocation, and then sends them down through the COW co
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 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 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_shash structure in the fs_info now, we can
> directly call into the crypto framework without goin
On 10 May 2019, at 7:15, Johannes Thumshirn wrote:
> Like btrfs_crc32c() btrfs_name_hash() is only a shim wrapper over the
> crc32c() library function. So we can just use btrfs_crc32c() instead
> of
> btrfs_name_hash().
Reading through the rest of the series, but I think using
btrfs_name_hash()
On 8 May 2019, at 3:15, Nikolay Borisov wrote:
> On 7.05.19 г. 20:27 ч., Josef Bacik wrote:
>> We have been seeing issues in production where a cleaner script will
>> end
>> up unlinking a bunch of files that have pending iputs. This means
>> they
>> will get their final iput's run at btrfs-cle
On 10 Apr 2019, at 2:51, Nikolay Borisov wrote:
> On 10.04.19 г. 9:34 ч., Qu Wenruo wrote:
>> Hi,
>>
>> As we have memleak.py in bcc tools, and it provides better info
>> including the calling stack, I'm wondering if we should replace
>> current
>> eb leakage check with bcc based one.
>>
>> Any i
On 19 Dec 2018, at 5:33, ethanlien wrote:
> Martin Raiber 於 2018-12-17 22:00 寫到:
>
>
I had lockups with this patch as well. If you put e.g. a loop
device on
top of a btrfs file, loop sets PF_LESS_THROTTLE to avoid a feed
back
loop causing delays. The task balancing d
On 12 Dec 2018, at 10:36, David Sterba wrote:
> On Wed, Dec 12, 2018 at 03:22:40PM +, Martin Raiber wrote:
>> On 12.12.2018 15:47 Chris Mason wrote:
>>> On 28 May 2018, at 1:48, Ethan Lien wrote:
>>>
>>> Eventually, we have every process in the system waiti
On 28 May 2018, at 1:48, Ethan Lien wrote:
It took me a while to trigger, but this actually deadlocks ;) More
below.
> [Problem description and how we fix it]
> We should balance dirty metadata pages at the end of
> btrfs_finish_ordered_io, since a small, unmergeable random write can
> potentia
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
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.
> But
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 using
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
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 c
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 wording
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 is
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
> crea
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 a
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, how
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 f
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 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
>>
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
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 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
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 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
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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 A
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 se
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 reproduc
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 persiste
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:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_XHaMLX8z&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9QPtTAxcitoznaWRKKHoEQ&m=IkofqwZ_
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]
[]
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 in
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)
fresh data in it.
This 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
Fixes: 6de5f18e7b0da
cc: #4.12
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
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 rout
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.
Signed-off-by: Jose
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 ensues.
Thanks Jo
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
I
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
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
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:
git://git.kernel.org/pub/scm/linux/kernel/gi
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.
Then
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-btr
Hmpf, forgot to put the sha in Linus' tree:
17024ad0a0fdfcfe53043afb969b813d3e020c21
-chris
On 08/11/2017 10:41 AM, Chris Mason wrote:
From: Omar Sandoval
If a lot of metadata is reserved for outstanding delayed allocations, we
rely on shrink_delalloc() to reclaim metadata space in ord
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:
https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git/commit/?h=for-stable-4.12&id=354850ad1948
quot;Btrfs: introduce ticketed enospc infrastructure")
Tested-by: Christoph Anton Mitterer
Cc: sta...@vger.kernel.org
Reviewed-by: Josef Bacik
Signed-off-by: Omar Sandoval
Signed-off-by: David Sterba
Signed-off-by: Chris Mason
---
fs/btrfs/extent-tree.c | 4
1 file changed, 4 del
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
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
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) |
|--|--|--|---|-
On 08/03/2017 11:25 AM, Wang Shilong wrote:
On Thu, Aug 3, 2017 at 11:00 PM, Chris Mason wrote:
On 07/27/2017 02:52 PM, fdman...@kernel.org wrote:
From: Filipe Manana
If the range being cleared was not marked for defrag and we are not
about to clear the range from the defrag status, we
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
-chris
--
To unsubscribe from this list: send the line &q
like it goes all the way back to:
commit 47059d930f0e002ff851beea87d738146804726d
Author: Wang Shilong
Date: Thu Jul 3 18:22:07 2014 +0800
Btrfs: make defragment work with nodatacow option
I can't see how the inode lock is required here.
Reviewed-by: Chris Mason
-chris
---
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 after unclean
shutdown we
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 lea
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" ha
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 manag
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 all
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 f
e possible 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
Fixes: 70e7af2 ("Btrfs: fix delalloc accounting leak caused by u32 overflow")
Signed-off-by: Chri
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
e possible 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
Fixes: 70e7af244f24c94604ef6eca32ad297632018583
Signed-off-by: Chris Mason
---
fs/btrfs/dev-replace.c |
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
In a heavy write scenario, we can end up with a large number of pinned
bytes. This can translate
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 when allowing a re
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 task.st
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 o
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 gi
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
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 i
OT (+23/-1)
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)
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 dis
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 to
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 changes since commi
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
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
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
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 (+11/-13
1 - 100 of 2656 matches
Mail list logo