Re: btrfs check --repair questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2018年08月03日 12:55, Nathan Dehnel wrote:
> Question 1: The command has been running for a couple days on a 10TB
> array with no visible change in output. Is it actually fixing anything?
> 
> enabling repair mode
> Checking filesystem on
> /dev/disk/by-uuid/e1ee5980-c54b-4b6e-82e2-3dbdcee1dd24
> UUID: e1ee5980-c54b-4b6e-82e2-3dbdcee1dd24
> checking extents
> Fixed 0 roots.
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> root 5 inode 5043370 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 50331648

If none of above numbers changes, it's a dead loop.

[snip]
> 
> Question 2: I accidentally interrupted the command by logging out. How
> dangerous is this? Should I be worried?

Not more dangerous than --repair itself.
As normally we do repair following metadata CoW, so it should be OK to
interrupt.

You should worry the first time you run --repair, other than worrying
about interruption.

Thanks,
Qu


Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux