On 02/26/2016 01:59 AM, David Sterba wrote:
On Mon, Feb 15, 2016 at 06:33:56PM +0100, David Sterba wrote:
this patchset extends the ioctl arugments to take an id so we can delete a
device by it. It reuses the existing structure btrfs_ioctl_vol_args_v2 and
extends it in na backward-compatible way so that we don't need to introduce
another one.
The core patchset is from Anand, I did some cleanups as I went through the
series again and made some cleanups and minor naming tweaks to the interface.
I'll add the branch to for-next and if everything goes fine I'll send a pull
request for 4.6 in a week.
This patchset is causing crashes in my setup, based on linux-next tree
with my for-next. I did a test round without it and it passes, so I'm
removing it from 4.6 queue. We need more time to find and fix it.
(crash.. are you ref to the below ?)
BUG: unable to handle kernel NULL pointer dereference
scrub_setup_ctx.isra.19+0x1f6/0x260 [btrfs]
Current status: as of now there is nothing that tells me the
above crash was due to the set of patches in here, if there
are further data I will be happy to review, also this wasn't
reproducible.
Also:
Most of the xfstest btrfs/tests aren't designed to generate a
consistent result, it can be consistent with a sequence of tests,
but when this sequence of tests is altered, it may generate
different results.
As xfstest results also depends on the factors like state of
stale FSID on the devices and state of btrfs_device list with
in the kernel, which depends on the previous tests.
And looks like following changes can make it consistent.
Before each test/sub-test:
. wipefs -a of all scratch pool dev
. modprobe -r btrfs && modprobe btrfs
So that kernel will have a clean state of btrfs_device list.
Which means all the btrfs tests especially which are grouped
under replace should be updated with the above change, So that
we can ensure kernel and devices are in the same state each
time the test is run.
Any idea?
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
