On Thu, Apr 14, 2016 at 04:45:11PM +0800, Anand Jain wrote: > > > > Thanks for the report ! more below.. > > > You may use simpler devmgt tool, https://github.com/asj/devmgt
Thanks, will try. > > You are failing the replace-target, presumably when the replace is > still running, however note that this patch-set does not fail the > replace-target for errors (as of now I have no idea how to do that > without leading to a messy situation), and so it would follow the > original code as without this patch. > Next, originally with-out this patch-set we won't close any device > for errors. So when you delete the device at the block-layer and > re-attach (scan) most probably you are having a newer device path > to the block device. (which kind of defeats the idea of testing > an intermittently disappearing device), so I doubt, if the test > case is reliable, and above panic is btrfs related and if its > this patch-set related. No, It is fixed by my latest patch (about of s_bdev field in superblock). Actual sequence which leads to oops is: 1) FS is mounted, s_bdev is NULL 2) failed device is closed, s_bdev untouched 3) missing device is replaced, s_bdev is set to non-NULL – bdev of the replaced device 4) at second device closing, s_bdev is "changed" to first device from the device list but it is... some device because closed dev still didn't delete from the list! 5) after device closing, s_bdev points to invalid bdev. 6) umount -> sync_filesystem() -> sync_blokdev(s_bdev) -> OOPS. -- Yauhen Kharuzhy -- 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
