Wiki

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
A scrub can fix everything that btrfs kernel code can recover from, i.e.
if a disk in a btrfs RAID array is 100% corrupted while online, scrub
can restore all of the data, including superblocks, without interrupting
application activity on the filesystem.  With RAID1/5/6/10 this includes
all single-disk failures and non-malicious data corruption from disks
(RAID6 does not have a corresponding 3-copy RAID1 profile for metadata
yet, so RAID6 can't always survive 2 disk failures in practice).

Scrub is very effective at repairing data damage caused by disk failures
in RAID arrays, and with DUP metadata on single-disk filesystem scrub can
often recover from a few random UNC sectors.  If something happens to the
filesystem that scrub can't repair (e.g. damage caused by accidentally
overwriting the btrfs partition with another filesystem, host RAM failures
writing corrupted data to disks, hard drive firmware write caching bugs),
the other tools usually can't repair it either.

Always use DUP or RAID1 or RAID10 for metadata.  Do not use single, RAID0,
RAID5, or RAID6--if there is a UNC sector error or data corruption in
a metadata page, the filesystem will be broken, and data losses will be
somewhere between "medium" and "severe".

The other utilities like 'btrfs check --repair' are in an experimental
state of development, and may make a damaged filesystem completely
unreadable.  They should only be used as a last resort, with expert
guidance, after all other data recovery options have been tried, if
at all.  Often when a filesystem is damaged beyond the ability of scrub
to recover, the only practical option is to mkfs and start over--but
ask the mailing list first to be sure, doing so might help improve the
tools so that this is no longer the case.

Usually a damaged btrfs can still be mounted read-only and some data
can be recovered.  Corrupted data blocks (with non-matching csums) are
not allowed to be read through a mounted filesystem.  'btrfs restore'
is required to read those.

'btrfs restore' can copy data from a damaged btrfs filesystem that is
not mounted.  It is able to work in some cases where mounting fails.
When 'btrfs restore' copies data it does not verify csums.  This can be
used to recover corrupted data that would not be allowed to read through
a mounted filesystem.  On the other hand, if you want to avoid copying
data with known corruption, you should mount the filesystem read-only
and read it that way.

Use 'btrfs replace' to replace failed disks in a RAID1/RAID5/RAID6/RAID10
array.  It can reconstruct data from other mirror disks quickly by
simply copying the mirrored data without changing any of the filesystem
structure that references the data.  If the replacement disk is smaller
than the disk it is meant to replace, then use 'btrfs dev add' followed by
'btrfs dev remove', but this is much slower as the data has to be moved
one extent at a time, and all references to the data must be updated
across the array.

There appear to be a few low-end hard drive firmwares in the field with
severe write caching bugs.  The first sign that you have one of those is
that btrfs gets an unrecoverable 'parent transid verify failure' event
after a few power failures.  The only known fix for this is to turn off
write caching on such drives (i.e. hdparm -W0), mkfs, and start over.
If you think you have encountered one of these, please post to the
mailing list with drive model and firmware revision.

'btrfs rescue' is useful for fixing bugs caused by old mkfs tools or
kernel versions.  It is not likely you will ever need it if you mkfs a
new btrfs today (though there's always the possibility of new bugs in
the future...).


(extract from a post of Zygo Blaxell on linux-btrfs@vger.kernel.org 3 july 2019 6:37AM)