[PATCH] btrfs: disk-io: Allow 0 as tree block bytenr

2017-12-09 Thread Qu Wenruo
Some btrfs created by old mkfs.btrfs can have tree block with 0 bytenr. In fact, any aligned bytenr is allowed in btrfs, and in some case it can cause problem if the valid tree block at 0 bytenr can't be read. Currently, the superblock checker and bytenr alignment checker can already handle the

Re: Odd behaviour of replace -- unknown resulting state

2017-12-09 Thread Duncan
Hugo Mills posted on Sat, 09 Dec 2017 17:43:48 + as excerpted: > This is on 4.10, so there may have been fixes made to this since > then. If so, apologies for the noise. > >I had a filesystem on 6 devices with a badly failing drive in it > (/dev/sdi). I replaced the drive with a new one:

Re: Chunk-Recovery fails with alignment error

2017-12-09 Thread Qu Wenruo
On 2017年12月10日 08:29, Qu Wenruo wrote: > > > On 2017年12月10日 07:12, Benjamin Beichler wrote: >> Hi Qu, >> >> 2017-12-07 12:09 GMT+00:00 Qu Wenruo : >>> >>> Since the btrfs chunk recovery doesn't work and my dirty quick hack >>> doesn't work either, I don't expect much to

Re: Chunk-Recovery fails with alignment error

2017-12-09 Thread Qu Wenruo
On 2017年12月10日 07:12, Benjamin Beichler wrote: > Hi Qu, > > 2017-12-07 12:09 GMT+00:00 Qu Wenruo : >> >> Since the btrfs chunk recovery doesn't work and my dirty quick hack >> doesn't work either, I don't expect much to recovery. >> >> Unless we have more detailed info

Re: Chunk-Recovery fails with alignment error

2017-12-09 Thread Benjamin Beichler
Hi Qu, 2017-12-07 12:09 GMT+00:00 Qu Wenruo : > > Since the btrfs chunk recovery doesn't work and my dirty quick hack > doesn't work either, I don't expect much to recovery. > > Unless we have more detailed info about the how and why the BUG_ON() of > chunk recovery is

Re: Odd behaviour of replace -- unknown resulting state

2017-12-09 Thread Hugo Mills
On Sat, Dec 09, 2017 at 05:43:48PM +, Hugo Mills wrote: >This is on 4.10, so there may have been fixes made to this since > then. If so, apologies for the noise. > >I had a filesystem on 6 devices with a badly failing drive in it > (/dev/sdi). I replaced the drive with a new one: > >

[GIT PULL] Btrfs fixes for 4.15-rc3

2017-12-09 Thread David Sterba
Hi, this update contains a few fixes (error handling, quota leak, FUA vs nobarrier mount option). There's one one worth mentioning separately - an off-by-one fix that leads to overwriting first byte of an adjacent page with 0, out of bounds of the memory allocated by an ioctl. This is under a

Odd behaviour of replace -- unknown resulting state

2017-12-09 Thread Hugo Mills
This is on 4.10, so there may have been fixes made to this since then. If so, apologies for the noise. I had a filesystem on 6 devices with a badly failing drive in it (/dev/sdi). I replaced the drive with a new one: # btrfs replace start /dev/sdi /dev/sdj /media/video Once it had

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

2017-12-09 Thread Joe Perches
On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote: > 1. Using lockdep_set_novalidate_class() for anything other > than device->mutex will throw checkpatch warnings. Nice. (*) [] > (*) checkpatch.pl is considered mostly harmful round here, too, > but that's another rant How so?

Re: [PATCH] Btrfs: raid56: fix race between merge_bio and rbio_orig_end_io

2017-12-09 Thread Nikolay Borisov
On 9.12.2017 01:02, Liu Bo wrote: > We're not allowed to take any new bios to rbio->bio_list in > rbio_orig_end_io(), otherwise we may get merged with more bios and > rbio->bio_list is not empty. > > This should only happens in error-out cases, the normal path of > recover and full stripe