On Jul 22, 2014, at 9:36 PM, Liu Bo <bo.li.liu@xxxxxxxxxx> wrote: > On Tue, Jul 22, 2014 at 09:28:52PM -0600, Chris Murphy wrote: >> >> On Jul 22, 2014, at 8:52 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >> >>> This one (your bug #4) was likely caused by: >>> >>> commit 99994cde9c59c2b8bb67d46d531b26cc73e39747 >>> Author: Anand Jain <Anand.Jain@xxxxxxxxxx> >>> Date: Tue Jun 3 11:36:00 2014 +0800 >>> >>> btrfs: dev delete should remove sysfs entry >>> >>> and hopefully fixed by: >>> >>> commit 0bfaa9c5cb479cebc24979b384374fe47500b4c9 >>> Author: Eric Sandeen <sandeen@xxxxxxxxxx> >>> Date: Mon Jul 7 12:34:49 2014 -0500 >>> >>> btrfs: test for valid bdev before kobj removal in btrfs_rm_device >> >> OK good. Hopefully the first one is reverted or the second one is accepted before 3.16 is released, replace appears to be broken at the moment. >> > > Looks that they are not the same one, since you didn't use a btrfs_rm_device, > > As we just skip adding a sysfs entry for a missing device(dev->bdev is NULL), we > can do the same thing in removing a sysfs entry, could you please try this? Normally yes, but not for a couple weeks this time. While replace cancel worked, and balance conversion back to single profile worked, I forgot to immediately device delete missing, and instead I rebooted. Now I can't mount degraded, and I run into this old bug: [ 71.064352] BTRFS info (device sdb): allowing degraded mounts [ 71.064812] BTRFS info (device sdb): enabling auto recovery [ 71.065210] BTRFS info (device sdb): disk space caching is enabled [ 71.072068] BTRFS warning (device sdb): devid 2 missing [ 71.097320] BTRFS: too many missing devices, writeable mount is not allowed [ 71.116616] BTRFS: open_ctree failed Since I can't mount degraded rw I can't make read-only snapshots, and can't btrfs send receive the subvolumes, so this setup will need to be replaced. Not a big deal, just time, but maybe someone else can test it sooner than me. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
