On Fri, Mar 30, 2018 at 06:14:52PM +0200, Goffredo Baroncelli wrote: > On 03/29/2018 11:50 PM, Zygo Blaxell wrote: > > On Wed, Mar 21, 2018 at 09:02:36PM +0100, Christoph Anton Mitterer wrote: > >> Hey. > >> > >> Some things would IMO be nice to get done/clarified (i.e. documented in > >> the Wiki and manpages) from users'/admin's POV: > [...] > > > > btrfs has no optimization like mdadm write-intent bitmaps; recovery > > is always a full-device operation. In theory btrfs could track > > modifications at the chunk level but this isn't even specified in the > > on-disk format, much less implemented. > > It could go even further; it would be sufficient to track which > *partial* stripes update will be performed before a commit, in one > of the btrfs logs. Then in case of a mount of an unclean filesystem, > a scrub on these stripes would be sufficient. A scrub cannot fix a raid56 write hole--the data is already lost. The damaged stripe updates must be replayed from the log. A scrub could fix raid1/raid10 partial updates but only if the filesystem can reliably track which blocks failed to be updated by the disconnected disks. It would be nice if scrub could be filtered the same way balance is, e.g. only certain block ranges, or only metadata blocks; however, this is not presently implemented. > BR > G.Baroncelli > > [...] > > > -- > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 > -- > 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
Attachment:
signature.asc
Description: PGP signature
