On 07/10/2018 06:53 PM, Su Yue wrote:
On 07/10/2018 12:10 PM, Marc MERLIN wrote:
On Tue, Jul 10, 2018 at 08:56:15AM +0800, Su Yue wrote:
I'm just not clear if my FS is still damaged and btrfsck was just
hacked to
ignore the damage it can't deal with, or whether it was able to repair
things to a consistent state.
The fact that I can mount read/write with no errors seems like a
good sign.
Yes, a good sign. Since extent tree is fixed, the errors left are in
other trees. The most bad result I can see is that writes of some
files will
reports IO Error. This is the cost of RW.
Ok, so we agreed that btrfs scrub won't find this, so ultimately I
should run normal btrfsck --repair without the special block skip code
you added?
Yes. Here is the normal btrfsck which skips extent tree to save time.
And I fixed a bug which is mentioned in other mail by Qu.
I have no time to add progress of fs trees check though.
https://github.com/Damenly/btrfs-progs/tree/tmp1
It may take a long time to fix errors unresolved.
#./btrfsck -e 2 --mode=lowmem --repair $dev
'-e' means to skip extent tree.
Here is the mail. Running above command should sloves errors.
If no other errors occurs, your FS will be good.
Please not run repair of master branch, please :(.
It will ruin all things we did in recent days.
Thanks,
Su
Thanks
Su
Since I can mount the filesystem read/write though, I can probably
delete a lot of snapshots to help the next fsck to run.
I assume the number of snapshots also affects the amount of memory taken
by regular fsck, so maybe if I delete enough of them regular fsck
--repair will work again?
Thanks,
Marc
--
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
