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
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
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
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
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 obvious problem I found is, the idea only works for RAID1/10.
For striped profile it make
On 2019/3/20 上午7:41, Anand Jain wrote:
>
>>> But csum verification is a point in verification and its not a
>>> tree based transid verification. Which means if there is a stale data
>>> with matching csum we may return a junk data silently.
>>
>> Then the normal idea is to use stronger but
But csum verification is a point in verification and its not a
tree based transid verification. Which means if there is a stale data
with matching csum we may return a junk data silently.
Then the normal idea is to use stronger but slower csum in the first
place, to avoid the csum match
On 2019/3/19 下午7:35, Anand Jain wrote:
>In case of file regular extent (non inline), the metadata and data are
> read from two different IO operations. When we read the metadata using
> the btree each extent block gets verified with the expected transid as
> per its parent. So suppose
In case of file regular extent (non inline), the metadata and data are
read from two different IO operations. When we read the metadata using
the btree each extent block gets verified with the expected transid as
per its parent. So suppose if any of the block is stale it gets reported
a
13 matches
Mail list logo
