On 10.08.19 г. 3:30 ч., Qu Wenruo wrote:
>
>
> On 2019/8/10 上午12:10, Nikolay Borisov wrote:
>>
>>
>> On 9.08.19 г. 9:53 ч., Qu Wenruo wrote:
>>> Since kernel is going to reject any root item which is newer than super
>>> block generation, we need to provide a way to fix such problem in
>>> btr
On Fri, Aug 09, 2019 at 05:50:40PM -0700, Eric Biggers wrote:
> On Fri, Aug 09, 2019 at 05:31:35PM -0700, Eric Biggers wrote:
> > On Sat, Aug 10, 2019 at 07:45:59AM +0800, Gao Xiang wrote:
> > > Hi Willy,
> > >
> > > On Fri, Aug 09, 2019 at 01:45:17PM -0700, Matthew Wilcox wrote:
> > > > On Wed, A
On Fri, Aug 09, 2019 at 05:31:36PM -0700, Eric Biggers wrote:
> On Sat, Aug 10, 2019 at 07:45:59AM +0800, Gao Xiang wrote:
> > Hi Willy,
> >
> > On Fri, Aug 09, 2019 at 01:45:17PM -0700, Matthew Wilcox wrote:
> > > On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> > > > On Thu, Aug 0
On 2019/8/9 下午9:18, Josef Bacik wrote:
> We don't update the inode when evicting it, so the nbytes will be wrong
> in between transaction commits. This isn't a problem, stop complaining
> about it to make generic/269 stop randomly failing.
Would you like to add the same check for lowmem mode?
On Fri, Aug 09, 2019 at 05:31:35PM -0700, Eric Biggers wrote:
> On Sat, Aug 10, 2019 at 07:45:59AM +0800, Gao Xiang wrote:
> > Hi Willy,
> >
> > On Fri, Aug 09, 2019 at 01:45:17PM -0700, Matthew Wilcox wrote:
> > > On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> > > > On Thu, Aug 0
On 2019/8/10 上午12:10, Nikolay Borisov wrote:
>
>
> On 9.08.19 г. 9:53 ч., Qu Wenruo wrote:
>> Since kernel is going to reject any root item which is newer than super
>> block generation, we need to provide a way to fix such problem in
>> btrfs-check.
>>
>> This patch addes the ability to report
On Sat, Aug 10, 2019 at 07:45:59AM +0800, Gao Xiang wrote:
> Hi Willy,
>
> On Fri, Aug 09, 2019 at 01:45:17PM -0700, Matthew Wilcox wrote:
> > On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> > > On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> > > > 1. decrypt->veri
On Fri, Aug 09, 2019 at 01:45:17PM -0700, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> > On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> > > 1. decrypt->verity->decompress
> > >
> > > 2. verity->decompress->decrypt
> > >
> > > 3.
Hi Willy,
On Fri, Aug 09, 2019 at 01:45:17PM -0700, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> > On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> > > 1. decrypt->verity->decompress
> > >
> > > 2. verity->decompress->decrypt
> > >
>
On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote:
> On Thu, Aug 08, 2019 at 12:26:42PM +0800, Gao Xiang wrote:
> > 1. decrypt->verity->decompress
> >
> > 2. verity->decompress->decrypt
> >
> > 3. decompress->decrypt->verity
> >
> >1. and 2. could cause less computatio
On 9.08.19 г. 9:53 ч., Qu Wenruo wrote:
> Since kernel is going to reject any root item which is newer than super
> block generation, we need to provide a way to fix such problem in
> btrfs-check.
>
> This patch addes the ability to report and repair root generation in
> lowmem mode.
>
> This
On Fri, Aug 09, 2019 at 06:27:14PM +0300, Nikolay Borisov wrote:
>
>
> On 9.08.19 г. 16:18 ч., Josef Bacik wrote:
> > We don't update the inode when evicting it, so the nbytes will be wrong
> > in between transaction commits. This isn't a problem, stop complaining
> > about it to make generic/26
On 9.08.19 г. 16:18 ч., Josef Bacik wrote:
> We don't update the inode when evicting it, so the nbytes will be wrong
> in between transaction commits. This isn't a problem, stop complaining
> about it to make generic/269 stop randomly failing.
>
> Signed-off-by: Josef Bacik
We shouldn't be a
Remove the callback indirection.
David Sterba (2):
btrfs: define compression levels statically
btrfs: compression: replace set_level callbacks by a common helper
fs/btrfs/compression.c | 20 ++--
fs/btrfs/compression.h | 11 +--
fs/btrfs/lzo.c | 8 ++--
f
The set_level callbacks do not do anything special and can be replaced
by a helper that uses the levels defined in the tables.
Signed-off-by: David Sterba
---
fs/btrfs/compression.c | 20 ++--
fs/btrfs/compression.h | 9 ++---
fs/btrfs/lzo.c | 6 --
fs/btrfs/zli
The maximum and default levels do not change and can be defined
directly. The set_level callback was a temporary solution and will be
removed.
Signed-off-by: David Sterba
---
fs/btrfs/compression.h | 4
fs/btrfs/lzo.c | 2 ++
fs/btrfs/zlib.c| 2 ++
fs/btrfs/zstd.c| 2
On 9.08.19 г. 17:07 ч., Dan Carpenter wrote:
> The btrfs_get_chunk_map() never returns NULL, it returns error pointers.
>
> Fixes: 89b798ad1b42 ("btrfs: Use btrfs_get_io_geometry appropriately")
> Signed-off-by: Dan Carpenter
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/volumes.c | 2 +-
>
The btrfs_get_chunk_map() never returns NULL, it returns error pointers.
Fixes: 89b798ad1b42 ("btrfs: Use btrfs_get_io_geometry appropriately")
Signed-off-by: Dan Carpenter
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/vo
On Thu, Aug 08, 2019 at 11:55:37PM +, WenRuo Qu wrote:
>
>
> On 2019/8/8 下午10:54, David Sterba wrote:
> > On Wed, Aug 07, 2019 at 10:08:41PM +0800, Qu Wenruo wrote:
> >> +
> >> +static int check_extent_item(struct extent_buffer *leaf,
> >> + struct btrfs_key *key, int sl
Now that btrfs_space_info_add_old_bytes simply checks if we can make the
reservation and updates bytes_may_use, there's no reason to have both
helpers in place. Factor out the ticket wakeup logic into it's own
helper, make btrfs_space_info_add_old_bytes() update bytes_may_use and
then call the wak
We duplicate this tracepoint everywhere we call these helpers, so update
the helper to have the tracepoint as well.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c| 3 ---
fs/btrfs/block-rsv.c | 5 -
fs/btrfs/delalloc-space.c | 4
fs/btrfs/extent-tree.c| 9 ---
Now that we no longer partially fill tickets we need to rework
wake_all_tickets to call btrfs_try_to_wakeup_tickets() in order to see
if any subsequent tickets are able to be satisfied. If our tickets_id
changes we know something happened and we can keep flushing.
Signed-off-by: Josef Bacik
---
If we already have tickets on the list we don't want to steal their
reservations. This is a preparation patch for upcoming changes,
technically this shouldn't happen today because of the way we add bytes
to tickets before adding them to the space_info in most cases.
Signed-off-by: Josef Bacik
--
Now that we do not do partial filling of tickets simply remove
orig_bytes, it is no longer needed.
Signed-off-by: Josef Bacik
---
fs/btrfs/space-info.c | 15 ---
fs/btrfs/space-info.h | 1 -
2 files changed, 16 deletions(-)
diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
While cleaning up some things around the global reserve and can_overcommit I
started getting ENOSPC's with plenty of space to make reservations. The root
cause of the problem has to do with how we satisfy ticket reservations.
Previously we would add any space we were returning to the space info t
If there are pending tickets and we are overcommitted we will simply
return free'd reservations to space_info->bytes_may_use if we cannot
overcommit any more. This is problematic because we assume any free
space would have been added to the tickets, and so if we go from an
overcommitted state to n
I noticed when folding the trace_btrfs_space_reservation() tracepoint
into the btrfs_space_info_update_* helpers that we didn't emit a
tracepoint when doing btrfs_add_reserved_bytes(). I know this is
because we were swapping bytes_may_use for bytes_reserved, so in my mind
there was no reason to ha
We don't update the inode when evicting it, so the nbytes will be wrong
in between transaction commits. This isn't a problem, stop complaining
about it to make generic/269 stop randomly failing.
Signed-off-by: Josef Bacik
---
check/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
bugzilla-dae...@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #10 from David Sterba (dste...@suse.com) ---
> In my case it happened on 5.3-rc3, with a strestest. The same machine has been
> running fstests periodically, with slab debug on, but ther
29 matches
Mail list logo
