On Mon, Dec 18, 2017 at 03:28:14PM -0700, Chris Murphy wrote: > On Mon, Dec 18, 2017 at 1:49 AM, Anand Jain <anand.j...@oracle.com> wrote: > > Agreed. IMO degraded-raid1-single-chunk is an accidental feature > > caused by [1], which we should revert back, since.. > > - balance (to raid1 chunk) may fail if FS is near full > > - recovery (to raid1 chunk) will take more writes as compared > > to recovery under degraded raid1 chunks > > The advantage of writing single chunks when degraded, is in the case > where a missing device returns (is readded, intact). Catching up that > device with the first drive, is a manual but simple invocation of > 'btrfs balance start -dconvert=raid1,soft -mconvert=raid1,soft' The > alternative is a full balance or full scrub. It's pretty tedious for > big arrays. > > mdadm uses bitmap=internal for any array larger than 100GB for this > reason, avoiding full resync. > > 'btrfs sub find' will list all *added* files since an arbitrarily > specified generation; but not deletions.
This is fine as scrub cares about extents not files. The newer generation of metadata doesn't have a reference to the deleted extent anymore. Selective scrub hasn't been implemented, but it should be pretty straightforward -- unless nocow is involved. Correct me if I'm wrong, but I believe there's no way to tell which copy of a nocow extent is the good one. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices. -- 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
