There are a bunch of filesystems which essentially open-code lru_to_page
helper. Change them to using the helper. No functional changes.
Signed-off-by: Nikolay Borisov
---
Since this is a mostly mechanical change I've actually batched all of them in
a single patch.
fs/afs/file.c| 5 +
Hello,
syzbot found the following crash on:
HEAD commit:ef78e5ec9214 ia64: export node_distance function
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1514f73340
kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
dashboard link
On 29.11.18 г. 5:33 ч., Lu Fengqi wrote:
> The @found is always false when it comes to the if branch. Besides, the
> bool type is more suitable for @found. Change the return value of the
> function and its caller to bool as well.
>
> Signed-off-by: Lu Fengqi
Reviewed-by: Nikolay Borisov
> -
The @found is always false when it comes to the if branch. Besides, the
bool type is more suitable for @found. Change the return value of the
function and its caller to bool as well.
Signed-off-by: Lu Fengqi
---
fs/btrfs/extent_io.c | 31 +++
fs/btrfs/exte
On Wed, Nov 28, 2018 at 07:20:51PM -0700, Jens Axboe wrote:
> On 11/28/18 6:30 PM, Ming Lei wrote:
> >> I'm going back and forth on those one a bit. Any concerns with
> >> pushing this to 4.22?
> >
> > My only one concern is about the warning of
> > "blk_cloned_rq_check_limits: over max segments l
On 11/28/18 6:30 PM, Ming Lei wrote:
>> I'm going back and forth on those one a bit. Any concerns with
>> pushing this to 4.22?
>
> My only one concern is about the warning of
> "blk_cloned_rq_check_limits: over max segments limit" on dm multipath,
> and seems Ewan and Mike is waiting for this fix
On Wed, Nov 28, 2018 at 06:44:00AM -0700, Jens Axboe wrote:
> On 11/25/18 7:17 PM, Ming Lei wrote:
> > Hi,
> >
> > This patchset brings multi-page bvec into block layer:
> >
> > 1) what is multi-page bvec?
> >
> > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages
> > which
On 2018/11/29 上午4:08, Filipe Manana wrote:
> On Wed, Nov 28, 2018 at 7:09 PM 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 +, Chris Mason wrote:
On 27 Nov 2018, at 14:54, Josef Bacik wrote:
> On Tu
On Wed, Nov 28, 2018 at 7:09 PM 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 +, Chris Mason wrote:
> > > On 27 Nov 2018, at 14:54, Josef Bacik wrote:
> > >
> > > > On Tue, Nov 27, 2018 at 10:26:15AM +0200, Nikolay B
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 +, Chris Mason wrote:
>>> On 27 Nov 2018, at 14:54, Josef Bacik wrote:
>>>
On Tue, Nov 27, 2018 at 10:26:15AM +0200, Nikolay Borisov wrote:
>>
On Tue, Nov 27, 2018 at 03:08:08PM -0500, Josef Bacik wrote:
> On Tue, Nov 27, 2018 at 07:59:42PM +, Chris Mason wrote:
> > 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 ч., Jose
On Thu, Nov 22, 2018 at 10:17:33AM +0200, Nikolay Borisov wrote:
> The first step fo the rebalance process, ensuring there is 1mb free on
> each device. This number seems rather small. And in fact when talking
> to the original authors their opinions were:
>
> "man that's a little bonkers"
> "i do
On Tue, Nov 27, 2018 at 09:56:43AM +0100, Johannes Thumshirn wrote:
> On 26/11/2018 19:37, David Sterba wrote:
> > I though a transaction abort would be here, as the state is not
> > consistent. Also I'm not sure what I as a user would get from such error
> > message after calling link(). If the er
On Wed, Nov 28, 2018 at 06:02:47PM +0100, David Sterba wrote:
> You've put your time to find and fix the typos so you deserve the
> credit. Because you sent them with the signed-off-by line I will use
Ok, David, thanks a lot.
So, I'm going to rework the patch with the various suggestion, and
then
On Wed, Nov 28, 2018 at 05:17:09PM +0100, Andrea Gelmini wrote:
> On Wed, Nov 28, 2018 at 04:56:20PM +0100, David Sterba wrote:
> > Thanks, such patches are accepted once in a while when the amount of new
> > typo fixes becomes noticeable.
>
> About this patch (and the others sent to this m/l), I
On 28.11.18 г. 18:46 ч., David Sterba wrote:
> On Tue, Nov 27, 2018 at 08:57:58PM +0200, Nikolay Borisov wrote:
>> This function really checks whether adding more data to the bio will
>> straddle a stripe/chunk. So first let's give it a more appropraite
>> name - btrfs_bio_fits_in_stripe. Second
On Tue, Nov 27, 2018 at 08:57:58PM +0200, Nikolay Borisov wrote:
> This function really checks whether adding more data to the bio will
> straddle a stripe/chunk. So first let's give it a more appropraite
> name - btrfs_bio_fits_in_stripe. Secondly, the offset parameter was
> never used to just rem
The pull request you sent on Wed, 28 Nov 2018 13:28:05 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.20-rc4-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/121b018f8c74b4e0ba81b4b8ee73a82db3f24b7b
Thank you!
--
Deet-doot-dot, I am a
On Wed, Nov 28, 2018 at 11:22:54AM +0800, Lu Fengqi wrote:
> When it is introduced at commit f094ac32aba3 ("Btrfs: fix NULL pointer
> after aborting a transaction"), it's useless.
>
> Signed-off-by: Lu Fengqi
Added to misc-next, thanks.
On Wed, Nov 28, 2018 at 09:04:31AM +0200, Nikolay Borisov wrote:
> On 28.11.18 г. 5:23 ч., Lu Fengqi wrote:
> > The generic_write_checks will check the combination of IOCB_NOWAIT and
> > !IOCB_DIRECT.
>
> True, however btrfs will return ENOSUPP whereas the generic code returns
> EINVAL. I guess th
On Wed, Nov 28, 2018 at 04:56:20PM +0100, David Sterba wrote:
>
> Thanks, such patches are accepted once in a while when the amount of new
> typo fixes becomes noticeable.
About this patch (and the others sent to this m/l), I don't
care to have them committed with my name.
Feel free to copy/inte
me, I explain further.
Anyway, here the rest of the story.
So, in the end I:
a) booted with 4.20.0-rc4
b) updated backup
c) did the btrfs check --read-only
d) seven steps, everything is perfect
e) no complains on screen or in logs (never had)
f) so, started to compile linux-next 20181128 (on anothe
On Wed, Nov 28, 2018 at 12:05:13PM +0100, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini
> ---
>
> Stupid fixes. Made on 4.20-rc4, and ported on linux-next (next-20181128).
Thanks, such patches are accepted once in a while when the amount of new
typo fixes becomes notice
On Wed, Nov 28, 2018 at 09:54:53AM +0100, Johannes Thumshirn wrote:
> While trying to understand the checksum code I came across some oddities
> regarding map_private_extent_buffer() and it's interaction with
> csum_tree_block().
>
> These patches address them but are either purely cosmetic or onl
On Wed, Nov 28, 2018 at 09:54:55AM +0100, Johannes Thumshirn wrote:
> In map_private_extent_buffer() use offset_in_page() to initialize
> 'start_offset' instead of open-coding it.
Can you please fix all instances where it's opencoded? Grepping for
'PAGE_SIZE - 1' finds a number of them. Thanks.
On Tue, Nov 27, 2018 at 04:24:03PM -0800, Omar Sandoval wrote:
> On Tue, Nov 27, 2018 at 08:53:41PM +0100, David Sterba wrote:
> > We can use simple enum for values that are not part of on-disk format:
> > global filesystem states.
>
> Reviewed-by: Omar Sandoval
>
> Some typos/wording suggestion
From: Filipe Manana
The log tree has a long standing problem that when a file is fsync'ed we
only check for new ancestors, created in the current transaction, by
following only the hard link for which the fsync was issued. We follow the
ancestors using the VFS' dget_parent() API. This means that
On Wed, Nov 28, 2018 at 2:22 PM David Sterba wrote:
>
> On Mon, Nov 26, 2018 at 08:10:30PM +, Filipe Manana wrote:
> > On Mon, Nov 26, 2018 at 6:17 PM David Sterba wrote:
> > >
> > > On Fri, Nov 23, 2018 at 06:25:40PM +, fdman...@kernel.org wrote:
> > > > From: Filipe Manana
> > > >
> >
From: Filipe Manana
The log tree has a long standing problem that when a file is fsync'ed we
only check for new ancestors, created in the current transaction, by
following only the hard link for which the fsync was issued. We follow the
ancestors using the VFS' dget_parent() API. This means that
On Mon, Nov 26, 2018 at 08:10:30PM +, Filipe Manana wrote:
> On Mon, Nov 26, 2018 at 6:17 PM David Sterba wrote:
> >
> > On Fri, Nov 23, 2018 at 06:25:40PM +, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > When a transaction commit starts, it attempts to pause scrub and
On Wed, Nov 28, 2018 at 11:21:12AM +0800, Su Yue wrote:
> In function do_trimming(), block_group->lock should be unlocked first.
Please also write why this is correct and if there are any bad
consequences of the current behaviour. Thanks.
On 2018/11/28 下午3:20, Mikko Merikivi wrote:
> Well, excuse me for thinking it wouldn't since in md-raid it worked.
> https://wiki.archlinux.org/index.php/RAID#RAID_level_comparison
>
> Anyway, the error message is truly confusing for someone who doesn't
> know about btrfs's implementation. I sup
On 2018/11/28 下午9:25, David Sterba wrote:
> On Wed, Nov 28, 2018 at 09:33:50AM +0800, Qu Wenruo wrote:
>> On 2018/11/28 上午3:53, David Sterba wrote:
>>> This is motivated by a merging mistake that happened a few releases ago.
>>> Two patches updated BTRFS_FS_* flags independently to the same value
On 11/25/18 7:17 PM, Ming Lei wrote:
> Hi,
>
> This patchset brings multi-page bvec into block layer:
>
> 1) what is multi-page bvec?
>
> Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages
> which are physically contiguous instead of one single page used in linux
> kernel f
On 28.11.18 г. 15:24 ч., Brendan Hide wrote:
>
>
> On 11/28/18 1:23 PM, Nikolay Borisov wrote:
>>
>>
>> On 28.11.18 г. 13:05 ч., Andrea Gelmini wrote:
>>> Signed-off-by: Andrea Gelmini
>>> ---
>
>
>
>>>
>>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>>> index bab2f1983c07..babbd75d91
On 11/28/18 1:23 PM, Nikolay Borisov wrote:
On 28.11.18 г. 13:05 ч., Andrea Gelmini wrote:
Signed-off-by: Andrea Gelmini
---
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index bab2f1983c07..babbd75d91d2 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -104,7 +104,7 @@ stat
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key
On Wed, Nov 28, 2018 at 09:33:50AM +0800, Qu Wenruo wrote:
> On 2018/11/28 上午3:53, David Sterba wrote:
> > This is motivated by a merging mistake that happened a few releases ago.
> > Two patches updated BTRFS_FS_* flags independently to the same value,
> > git did not see any direct merge conflict
On Tue, Nov 27, 2018 at 04:37:16PM -0800, Omar Sandoval wrote:
> On Tue, Nov 27, 2018 at 08:53:55PM +0100, David Sterba wrote:
> > We can use simple enum for values that are not part of on-disk format:
> > tree lock types.
> >
> > Signed-off-by: David Sterba
> > ---
> > fs/btrfs/locking.h | 10 +
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes ThumshirnSUSE Labs
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Hi,
please pull the following fixes. Some of them are being hit during
testing so we'd like to get them merged, otherwise there are usual
stability fixes for stable trees. Thanks.
The following changes since commit d6fd0ae25c6495674
On 28.11.18 г. 13:05 ч., Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini
> ---
>
> Stupid fixes. Made on 4.20-rc4, and ported on linux-next (next-20181128).
>
>
> fs/btrfs/backref.c | 4 ++--
> fs/btrfs/check-integrity.c | 2 +-
> fs/btrfs/compre
Signed-off-by: Andrea Gelmini
---
Stupid fixes. Made on 4.20-rc4, and ported on linux-next (next-20181128).
fs/btrfs/backref.c | 4 ++--
fs/btrfs/check-integrity.c | 2 +-
fs/btrfs/compression.c | 4 ++--
fs/btrfs/ctree.c | 4 ++--
fs/btrfs/dev-replace.c | 2
On Wed, Nov 28, 2018 at 9:26 AM Lu Fengqi wrote:
>
> On Wed, Nov 28, 2018 at 09:48:07AM +0200, Nikolay Borisov wrote:
> >
> >
> >On 28.11.18 г. 9:46 ч., Christoph Hellwig wrote:
> >> On Wed, Nov 28, 2018 at 09:44:59AM +0200, Nikolay Borisov wrote:
> >>>
> >>>
> >>> On 28.11.18 г. 5:07 ч., Lu Fengq
On Wed, Nov 28, 2018 at 09:01:42AM +0200, Nikolay Borisov wrote:
>
>
>On 28.11.18 г. 5:21 ч., Lu Fengqi wrote:
>> The @found is always false when it comes to the if branch. Besides, the
>> bool type is more suitable for @found.
>
>Well if you are ranging the type of found variable it also makes sen
On Wed, Nov 28, 2018 at 09:48:07AM +0200, Nikolay Borisov wrote:
>
>
>On 28.11.18 г. 9:46 ч., Christoph Hellwig wrote:
>> On Wed, Nov 28, 2018 at 09:44:59AM +0200, Nikolay Borisov wrote:
>>>
>>>
>>> On 28.11.18 г. 5:07 ч., Lu Fengqi wrote:
The generic/513 tell that cloning into a file did not
On 11/28/18 4:24 PM, Nikolay Borisov wrote:
On 28.11.18 г. 5:11 ч., Su Yue wrote:
To implement priority aware allocator, this patch:
Introduces struct btrfs_priority_tree which contains block groups
in same level.
Adds member priority to struct btrfs_block_group_cache and pointer
points to
On 28.11.18 г. 10:54 ч., Johannes Thumshirn wrote:
> Document why map_private_extent_buffer() cannot return '1' (i.e. the map
> spans two pages) for the csum_tree_block() case.
>
> The current algorithm for detecting a page boundary crossing in
> map_private_extent_buffer() will return a '1' *I
On 28.11.18 г. 5:11 ч., Su Yue wrote:
> Introduce compute_block_group_usage() and compute_block_group_usage().
> And call the latter in btrfs_make_block_group() and
> btrfs_read_block_groups().
>
> compute_priority_level use ilog2(free) to compute priority level.
>
> Signed-off-by: Su Yue
> -
In map_private_extent_buffer() the 'offset' variable is initialized to a
page aligned version of the 'start' parameter.
But later on it is overwritten with either the offset from the extent
buffer's start or 0.
So get rid of the initial initialization.
Signed-off-by: Johannes Thumshirn
Reviewed
In map_private_extent_buffer() use offset_in_page() to initialize
'start_offset' instead of open-coding it.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs
Document why map_private_extent_buffer() cannot return '1' (i.e. the map
spans two pages) for the csum_tree_block() case.
The current algorithm for detecting a page boundary crossing in
map_private_extent_buffer() will return a '1' *IFF* the extent buffer's
offset in the page + the offset passed i
While trying to understand the checksum code I came across some oddities
regarding map_private_extent_buffer() and it's interaction with
csum_tree_block().
These patches address them but are either purely cosmetic or only add a
comment documenting behaviour.
Changes to v1:
* Add Reviewed-by tags
On 11/26/2018 05:59 PM, Nikolay Borisov wrote:
On 26.11.18 г. 11:07 ч., Anand Jain wrote:
Circular locking dependency check reports warning[1], that's because
the btrfs_scrub_dev() calls the stack #0 below with, the
fs_info::scrub_lock held. The test case leading to this warning..
mkfs.
On 27/11/2018 17:36, Nikolay Borisov wrote:
>
>
> On 27.11.18 г. 18:00 ч., Johannes Thumshirn wrote:
>> Document why map_private_extent_buffer() cannot return '1' (i.e. the map
>> spans two pages) for the csum_tree_block() case.
>>
>> The current algorithm for detecting a page boundary crossing i
On 28.11.18 г. 5:11 ч., Su Yue wrote:
> To implement priority aware allocator, this patch:
> Introduces struct btrfs_priority_tree which contains block groups
> in same level.
> Adds member priority to struct btrfs_block_group_cache and pointer
> points to the priority tree it's located.
>
> Ad
On 27.11.18 г. 21:46 ч., Josef Bacik wrote:
> On Mon, Nov 26, 2018 at 02:25:52PM +0200, Nikolay Borisov wrote:
>>
>>
>> On 21.11.18 г. 21:03 ч., Josef Bacik wrote:
>>> With the introduction of the per-inode block_rsv it became possible to
>>> have really really large reservation requests made be
64 matches
Mail list logo
