On 3/20/19 11:40 PM, Zygo Blaxell wrote:
On Wed, Mar 20, 2019 at 10:40:07PM +0800, Qu Wenruo wrote:
On 2019/3/20 下午10:00, Anand Jain wrote:
Also any idea why the generation number for the extent data is not
incremented [2] when -o nodatacow and notrunc option is used, is it
a bu
The uptodate parameter of btrfs_writepage_endio_finish_ordered is used
to signal whether an error has occured while writing the given page.
0 signal an error, which is propagated to callees and 1 signifies
success. In end_compressed_bio_write the ->bi_status is checked and
based on it either BLK_ST
On Wed, Mar 20, 2019 at 02:27:41PM +0800, Qu Wenruo wrote:
> We have a BUG_ON() in flush_write_bio() to handle the return value of
> submit_one_bio().
>
> Move the BUG_ON() one level up to all its callers.
>
> This patch will introduce temporary variable, @flush_ret to keep code
> change minimal
On Wed, Mar 20, 2019 at 09:54:16PM +0800, Anand Jain wrote:
>
>
> On 3/20/19 2:27 PM, Qu Wenruo wrote:
> >
> >
> > On 2019/3/20 下午1:47, Anand Jain wrote:
> > >
> > >
> > > > > > > A tree based integrity verification
> > > > > > > is important for all data, which is missing.
> > > > > > >
On Wed, Mar 20, 2019 at 10:40:07PM +0800, Qu Wenruo wrote:
>
>
> On 2019/3/20 下午10:00, Anand Jain wrote:
> >
> >>> Also any idea why the generation number for the extent data is not
> >>> incremented [2] when -o nodatacow and notrunc option is used, is it
> >>> a bug? the dump-tree is take
On 2019/3/20 下午10:00, Anand Jain wrote:
>
>>> Also any idea why the generation number for the extent data is not
>>> incremented [2] when -o nodatacow and notrunc option is used, is it
>>> a bug? the dump-tree is taken with the script as below [1]
>>> (this corruption is seen with or wit
Also any idea why the generation number for the extent data is not
incremented [2] when -o nodatacow and notrunc option is used, is it
a bug? the dump-tree is taken with the script as below [1]
(this corruption is seen with or without generation number is
being incremented, but as ano
On 3/20/19 2:27 PM, Qu Wenruo wrote:
On 2019/3/20 下午1:47, Anand Jain wrote:
A tree based integrity verification
is important for all data, which is missing.
Fix:
In this RFC patch it proposes to use same disk from with the
metadata
is read to read the data.
The obvi
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
Although I prefer direct returns instead of gotos if there's no cleanup.
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 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
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 2019/3/20 下午7:51, Johannes Thumshirn wrote:
> On 20/03/2019 07:37, Qu Wenruo wrote:
> [...]
>
>> +static int check_dev_item(struct btrfs_fs_info *fs_info,
>> + struct extent_buffer *leaf,
>> + struct btrfs_key *key, int slot)
>> +{
>> +struct btr
On 20/03/2019 07:37, Qu Wenruo wrote:
[...]
> +static int check_dev_item(struct btrfs_fs_info *fs_info,
> + struct extent_buffer *leaf,
> + struct btrfs_key *key, int slot)
> +{
> + struct btrfs_dev_item *ditem;
> + u64 max_devid = max(BTRFS_MAX_
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
Looks good,
Reviewed-by: Johannes Thumshirn
Although I think it would've been worth to explicitly mention that you
increased the severity level from error to critical.
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 91
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/03/2019 01:59, Christoph Anton Mitterer wrote:
> Anything I should do with respect to this?
>
> I.e. is further debug info needed for an interested developer? or can I
> simply scrap that particular image (which is not an important one)?
OK, I can give it a shot, but please be aware I'm st
19 matches
Mail list logo
