On Wed, Jul 12, 2017 at 03:35:43PM -0600, Liu Bo wrote:
> On Wed, Jul 12, 2017 at 11:46:29AM -0600, Liu Bo wrote:
> > On Wed, Jul 12, 2017 at 04:40:36PM +0200, David Sterba wrote:
> > > On Tue, Jul 11, 2017 at 02:43:16PM -0600, Liu Bo wrote:
> > > > When btrfs fails the checksum check, it'll fill t
On Wed, Jul 12, 2017 at 11:46:29AM -0600, Liu Bo wrote:
> On Wed, Jul 12, 2017 at 04:40:36PM +0200, David Sterba wrote:
> > On Tue, Jul 11, 2017 at 02:43:16PM -0600, Liu Bo wrote:
> > > When btrfs fails the checksum check, it'll fill the whole page with
> > > "1".
> >
> > One could ask, why is the
On Wed, Jul 12, 2017 at 04:40:36PM +0200, David Sterba wrote:
> On Tue, Jul 11, 2017 at 02:43:16PM -0600, Liu Bo wrote:
> > When btrfs fails the checksum check, it'll fill the whole page with
> > "1".
>
> One could ask, why is the page filled with 1s. Brought by commit
> 07157aacb1ecd394a54949 fro
On Tue, Jul 11, 2017 at 02:43:16PM -0600, Liu Bo wrote:
> When btrfs fails the checksum check, it'll fill the whole page with
> "1".
One could ask, why is the page filled with 1s. Brought by commit
07157aacb1ecd394a54949 from 2007, without mentioning any justification.
I'm more inclined to revisit
When btrfs fails the checksum check, it'll fill the whole page with
"1".
However, if %csum_expected is 0 (which means there is no checksum), then
for some unknown reason, we just pretend that the read is correct, so
userspace would be confused about the dilemma that read is successful but
getting
