On 2019/6/12 下午10:12, marcos k. wrote: > Hallo again, > > > > On Wednesday, 12 June 2019 15.47.49 CEST you wrote: > >> > The patch helped me a lot !!! ;-)) After compiling a new btrfs > >> > kernel-module with your small patch, the filesystem just mounted! After > >> > a "scub" and "balance" of the btrfs filesystem, it could be mounted with > >> > the regular btrfs kernel-module. So far so good ... > >> > > >> > After another full backup (rsync) of the home-directory I checked the > >> > filesystem again. The btrfs check indicated a lot of errors. > >> > >> Would you mind to share the output? > >> > > Strange enough I found a "check --repair" output of the corrupted > homefs. But the filesystem does not exist any more. I will attach the > output. So indeed some corruption. Some corruption in extent tree and some in fs tree. I'd say the corruption is pretty serious, not some simple one. But surprisingly, the btrfs-progs --repair doesn't make things worse. Either you're using the latest btrfs-progs or you're lucky. (older btrfs-progs could easily further corrupt the fs if btrfs check aborted). > > > > The png-files are cached icons from "~/.cache/thumbnails" > . It seems that most of the errors are cached data. To me, it looks like a failed metadata CoW. Would you mind to share about the layout of dm-2? Recently we have some reports of failed data/metadata CoW on device mapper devices. Not sure if dm is contributing to the problem. > >> > >> If scrub shows no error but check reports, then there is something wrong > >> in metadata, but not some serious corruption to prevent btrfs to read > >> the tree blocks. > >> > >> > I tried to > >> > remove all files and all directories (except the subvolume dirs) but > >> > cloudn't. I tried to check --repair, check --init-csum-tree > >> > , check --init-extent-tree the remainig files but without success. > >> > >> --init-csum/extent-tree normally makes no sense, except some special case. > >> And if --repair doesn't help, we need the original output to determine > >> what's wrong. > >> > > Yes I read about normaly not using --init-csum/extent-tree. Therefor I > did "check --repair" on the remaining files and dirs, then tried to > remove them, then did another "check --repair" on the remaining files, > tried to remove them .... So only after a lot of tries with "check > --repair" I did a last test with "--init-csum/extent-tree" and another > "check --repair", which did not help. Some dirs e.g. in > /home/user/.cache could not be removed. I remember --repair should have the ability to repair mismatch in INODE_ITEM/DIR_ITEM/DIR_INDEX. I may need to double check the repair code for that part. Thanks, Qu > >> > >> Thanks, > >> Qu > >> > >> > I had to make a new btrfs over the old one. After copying all the data > >> > back, everything is good now. > >> > > >> > > >> > > >> > Maybe a switch would be helpful to mount "old"-btrfses. Some user might > >> > not be able to patch and compile kernel-mudules. At least everybody > >> > should be informed to balance his "old" btrfs. > >> > > >> > > >> > > >> > Thanks a lot, marcos. k. > >> > > >> > > >> > > >> > > >> > > >> > > > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature
