Re: fsck: to repair or not to repair

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-06-09 23:40, Nikolaus Rath wrote:
> On May 11 2016, Nikolaus Rath <Nikolaus@rath.org> wrote:
>> Hello,
>>
>> I recently ran btrfsck on one of my file systems, and got the following
>> messages:
>>
>> checking extents
>> checking free space cache
>> checking fs roots
>> root 5 inode 3149867 errors 400, nbytes wrong
>> root 5 inode 3150237 errors 400, nbytes wrong
>> root 5 inode 3150238 errors 400, nbytes wrong
>> root 5 inode 3150242 errors 400, nbytes wrong
>> root 5 inode 3150260 errors 400, nbytes wrong
>> [ lots of similar message with different inode numbers ]
>> root 5 inode 15595011 errors 400, nbytes wrong
>> root 5 inode 15595016 errors 400, nbytes wrong
>> Checking filesystem on /dev/mapper/vg0-nikratio_crypt
>> UUID: 8742472d-a9b0-4ab6-b67a-5d21f14f7a38
>> found 263648960636 bytes used err is 1
>> total csum bytes: 395314372
>> total tree bytes: 908644352
>> total fs tree bytes: 352735232
>> total extent tree bytes: 95039488
>> btree space waste bytes: 156301160
>> file data blocks allocated: 675209801728
>>  referenced 410351722496
>> Btrfs v3.17
>>
>>
>> Can someone explain to me the risk that I run by attempting a repair,
>> and (conversely) what I put at stake when continuing to use this file
>> system as-is?
>
> To follow-up on this: after finding out which files were affected (using
> btrfs inspect-internal), I was able to fix the problem without using
> btrfsck by simply copying the data, deleting the file, and restoring it:
>
> cat affected-files.txt | while read -r name; do
> rsync -a "${name}" "/backup/location/${name}"
> rm -f "${name}"
> cp -a "/backup/location/${name}" "${name}"
> done
>
> (I used rsync to avoid cp making use of reflinks). After this procedure,
> btrfschk reported no more problems.
JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it 
making reflinks.