On 2019/2/18 下午1:27, Qu Wenruo wrote:
> Patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/write_time_tree_checker
> Which is based on v5.0-rc1 tag.
> Also there is no conflict rebasing the patchset to misc-next.
Now the github branch rebased to v5.0-rc7 tag.
And ra
On 2019/2/21 上午2:25, David Sterba wrote:
> On Mon, Feb 18, 2019 at 01:27:41PM +0800, Qu Wenruo wrote:
>> Patchset can be fetched from github:
>> https://github.com/adam900710/linux/tree/write_time_tree_checker
>> Which is based on v5.0-rc1 tag.
>
> Please base the patches on something new, a rec
On Sun, Feb 17, 2019 at 06:42:59PM -0500, Ric Wheeler wrote:
> I think the variability makes life really miserable for layers above it.
>
> Might be worth constructing some tooling that we can use to validate or
> shame vendors over - testing things like a full device discard, discard of
> fs bloc
On Tue, Feb 12, 2019 at 10:18:49AM +0800, Anand Jain wrote:
> btrfs_set_prop() is a redirect to __btrfs_set_prop() with the
> transaction handler equal to NULL. And __btrfs_set_prop() inturn diectly
> uses trans to do_setxattr() which when trans is NULL creates a transaction.
That's right and I th
On Mon, Feb 18, 2019 at 01:27:41PM +0800, Qu Wenruo wrote:
> Patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/write_time_tree_checker
> Which is based on v5.0-rc1 tag.
Please base the patches on something new, a recent rc is fine (rc6 or
rc7 depends what you've teste
On Mon, Feb 18, 2019 at 05:32:56PM +0800, Qu Wenruo wrote:
> [snip]
> >>
> >> Reported-by: Leonard Lausen
> >> Signed-off-by: Qu Wenruo
> >> ---
> >> fs/btrfs/disk-io.c | 10 ++
> >> fs/btrfs/tree-checker.c | 24 +---
> >> fs/btrfs/tree-checker.h | 8
>
On Wed, Feb 20, 2019 at 04:54:09PM +, Filipe Manana wrote:
> On Wed, Feb 20, 2019 at 4:42 PM Zygo Blaxell
> wrote:
> >
> > On Thu, Jan 31, 2019 at 04:39:22PM +, Filipe Manana wrote:
> > > On Thu, Dec 13, 2018 at 4:08 PM David Sterba wrote:
> > > >
> > > > On Wed, Dec 12, 2018 at 06:05:58P
On Wed, Feb 20, 2019 at 4:42 PM Zygo Blaxell
wrote:
>
> On Thu, Jan 31, 2019 at 04:39:22PM +, Filipe Manana wrote:
> > On Thu, Dec 13, 2018 at 4:08 PM David Sterba wrote:
> > >
> > > On Wed, Dec 12, 2018 at 06:05:58PM +, fdman...@kernel.org wrote:
> > > > From: Filipe Manana
> > > >
> >
On Thu, Jan 31, 2019 at 04:39:22PM +, Filipe Manana wrote:
> On Thu, Dec 13, 2018 at 4:08 PM David Sterba wrote:
> >
> > On Wed, Dec 12, 2018 at 06:05:58PM +, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Checking if the destination root is read-only was being performed
On 20/02/2019 16:11, Nikolay Borisov wrote:
> This commit changes the implementation of cow_file_range_async in order
> to get rid of the BUG_ON in the middle of the loop. Additionally it
> reworks the inner loop in the hopes of making it more understandable.
>
> Main change is that the number of
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 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
On 20.02.19 г. 17:25 ч., Johannes Thumshirn wrote:
> On 20/02/2019 16:11, Nikolay Borisov wrote:
>> We always pass an inode alongside async_cow. fs_info can be referenced
>> from this inode so it makes the explicit fs_info member in
>> struct async_cow redundant, remove it. No functional changes
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
Hmm "... and num_added" for the Subject?
--
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ürn
On 20/02/2019 16:11, Nikolay Borisov wrote:
> We always pass an inode alongside async_cow. fs_info can be referenced
> from this inode so it makes the explicit fs_info member in
> struct async_cow redundant, remove it. No functional changes.
[...]
> @@ -1151,13 +1150,10 @@ static noinline void as
The inode never changes so it's sufficient to dereference it and get
the iotree only once, before the execution of the main loop. No
functional changes, only the size of the function is decreased:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-44 (-44)
Function ol
Irrespective of whether the compress code fell back to uncompressed or
a compressed extent has to be submitted, the extent range is always
locked. So factor out the common lock_extent call at the beginning of
the loop. No functional changes just removes one duplicate lock_extent
call.
Signed-off-b
Here is v2 of the compressed path cleanups. The main objective was to remove
the BUG_ON in cow_file_range_async. This has been achieved by pre-allocating
an array large enough to hold all async_cow structs for the given range. In
case this allocation fail we just unlock the range and error out t
All context this function needs is held within struct async_cow.
Currently we not only pass the struct but also every individual member.
This is redundant, simplify it by only passing struct async_cow and
leaving it to compress_file_range to extract the values it requires.
No functional changes.
S
This commit changes the implementation of cow_file_range_async in order
to get rid of the BUG_ON in the middle of the loop. Additionally it
reworks the inner loop in the hopes of making it more understandable.
Main change is that the number of chunks required to handle the given
range is calculate
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 02666e584e28..c6ee1863cd20 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1199,8 +1199,7 @@ static int cow_file_range_async
We always pass an inode alongside async_cow. fs_info can be referenced
from this inode so it makes the explicit fs_info member in
struct async_cow redundant, remove it. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 9 ++---
1 file changed, 2 insertions(+), 7 de
On 2019/2/20 下午8:32, YueHaibing wrote:
> There is a messy cast here:
> min_t(int, len, (int)sizeof(*item)));
>
> min_t() should normally cast to unsigned. It's not possible for
> "len" to be negative, but if it were then we definitely
> wouldn't want to pass negatives to read_extent_buffe
On Wed, Feb 20, 2019 at 12:32:02PM +, YueHaibing wrote:
> There is a messy cast here:
> min_t(int, len, (int)sizeof(*item)));
>
> min_t() should normally cast to unsigned. It's not possible for
> "len" to be negative, but if it were then we definitely
> wouldn't want to pass negatives t
There is a messy cast here:
min_t(int, len, (int)sizeof(*item)));
min_t() should normally cast to unsigned. It's not possible for
"len" to be negative, but if it were then we definitely
wouldn't want to pass negatives to read_extent_buffer(). Also there
is an extra cast.
This patch shou
On 2019/2/20 下午7:11, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> At ctree.c:key_search(), the assertion that verifies the first key on a
> child extent buffer corresponds to the key at a specific slot in the
> parent has a disadvantage: we effectively hit a BUG_ON() which requires
> re
On Tue, Feb 19, 2019 at 12:26 PM Qu Wenruo wrote:
>
>
>
> On 2019/2/19 下午7:59, Filipe Manana wrote:
> > On Tue, Feb 19, 2019 at 12:54 AM Qu Wenruo wrote:
> >>
> >>
> >>
> >> On 2019/2/19 上午12:58, fdman...@kernel.org wrote:
> >>> From: Filipe Manana
> >>>
> >>> When there is a kind of corruption
From: Filipe Manana
At ctree.c:key_search(), the assertion that verifies the first key on a
child extent buffer corresponds to the key at a specific slot in the
parent has a disadvantage: we effectively hit a BUG_ON() which requires
rebooting the machine later. It also does not tell any informati
Provide an option in `btrfs receive` to suppress the informational
messages when writing files.
Signed-off-by: Steven Davies
---
cmds-receive.c | 67 ++
1 file changed, 40 insertions(+), 27 deletions(-)
diff --git a/cmds-receive.c b/cmds-receive.
On 2019/2/20 14:10, Dan Carpenter wrote:
> On Wed, Feb 20, 2019 at 08:58:43AM +0300, Dan Carpenter wrote:
>> On Wed, Feb 20, 2019 at 03:08:40AM +, YueHaibing wrote:
>>> btrfs_item_size_nr return value is u32, convert it to int may result
>>> in truncation.Also read_extent_buffer expect a unsi
31 matches
Mail list logo
