Re: btrfs check Causes File Corruption
On 20/08/2023 18:31, Longhao.Chen wrote: Only one file was erroneous, but now it's not just the erroneous file that has disappeared, over eight thousand other files have disappeared as well. The disappeared files seem to be those that were recently modified or newly created. I create a snapshot every day, and each snapshot is kept for a month. Those over eight thousand files have disappeared from all the snapshots. Sorry I can't help any further, your best course of action will be to head out to btrfs group. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: btrfs check Causes File Corruption
Only one file was erroneous, but now it's not just the erroneous file that has disappeared, over eight thousand other files have disappeared as well. The disappeared files seem to be those that were recently modified or newly created. I create a snapshot every day, and each snapshot is kept for a month. Those over eight thousand files have disappeared from all the snapshots. On August 20, 2023 5:03:12 PM UTC, piorunz wrote: >Ok. You said file with error has disappeared from the system. Is that >still the case? If there anything you need to "recover"? If file with >error is already gone, then you should have no more errors while reading >the drive to backup it. > > >On 20/08/2023 13:24, Longhao.Chen wrote: >> Thanks for your reply. >> >> The disk is a 1TB Samsung SSD with less than 4TiB written, the SMART is >> completely normal with no errors. I suspect that this error may have been >> caused by random bit flipping in the memory (DDR4 non-ECC memory). >> >> I just want to fix the checksum error (because the file with the checksum >> error is not important), so I used the command 'btrfs check >> --init-csum-tree'. >> >> 于 2023年8月20日 GMT+08:00 下午8:12:31, piorunz 写到: >>> On 20/08/2023 12:11, Longhao.Chen wrote: Thanks for your reply. I previously read in the btrfs documentation that "when repairing the file system, it is advisable to choose a newer kernel", so I used Ubuntu's livecd for the repair. >>> >>> First of all, did you found the cause of this unrepairable error? >>> Is HDD failing? What SMART data say? >>> You should not repair or use medium which is failing, it may cause >>> further damage. >>> >>> -- >>> With kindest regards, Piotr. >>> >>> ⢀⣴⠾⠻⢶⣦⠀ >>> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system >>> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ >>> ⠈⠳⣄ >>> >> > >-- >With kindest regards, Piotr. > >⢀⣴⠾⠻⢶⣦⠀ >⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system >⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ >⠈⠳⣄ >
Re: btrfs check Causes File Corruption
Ok. You said file with error has disappeared from the system. Is that still the case? If there anything you need to "recover"? If file with error is already gone, then you should have no more errors while reading the drive to backup it. On 20/08/2023 13:24, Longhao.Chen wrote: Thanks for your reply. The disk is a 1TB Samsung SSD with less than 4TiB written, the SMART is completely normal with no errors. I suspect that this error may have been caused by random bit flipping in the memory (DDR4 non-ECC memory). I just want to fix the checksum error (because the file with the checksum error is not important), so I used the command 'btrfs check --init-csum-tree'. 于 2023年8月20日 GMT+08:00 下午8:12:31, piorunz 写到: On 20/08/2023 12:11, Longhao.Chen wrote: Thanks for your reply. I previously read in the btrfs documentation that "when repairing the file system, it is advisable to choose a newer kernel", so I used Ubuntu's livecd for the repair. First of all, did you found the cause of this unrepairable error? Is HDD failing? What SMART data say? You should not repair or use medium which is failing, it may cause further damage. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄ -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: btrfs check Causes File Corruption
>Why not btrfs check? 'btrfs check' also reported a checksum error. >As already suggested, you might do better looking elsewhere for help. >Perhaps the linux-btrfs mailing list? Thank you for your suggestion, I am preparing to seek help from linux-btrfs mailing list. On August 20, 2023 12:54:01 PM UTC, debian-u...@howorth.org.uk wrote: >"Longhao.Chen" wrote: >> Hello everyone, I use Btrfs as the file system on my laptop. >> Yesterday, I was preparing to backup a snapshot to an external hard >> drive using btrfs send, and the following error occurred: >> >> ERROR: send ioctl failed with -5: Input/Output error > >I use btrfs but don't know much about it :( I certainly know nothing >about btrfs send, but the error seems to suggest perhaps an error with >the send rather than with reading the source? > >> I used btrfs scrub to scan the disk, and the result was: > >Why not btrfs check? > >> Error summary:csum=1 >> >> Corrected: 0 >> >> Uncorrectable: 1 >> >> Unverified: 0 > >OK so that sounds like a hardware problem. > >> Afterwards, I booted a LiveCD and ran: >> >> btrfs check --init-csum-tree >> >> During the running process, many outputs similar to this appeared: >> >> root 1380 inode 5006723 errors 2001, no inode item, link count wrong >> unresolved ref dir 1164151 index 1566 namelen 28 name >> filetype 1 errors 4, no inode ref >> >> Then I found that the file in the above had disappeared. >> At this point, I immediately backed up all the existing files and >> then used: >> >> btrfs check --repair >> >> btrfs rescue >> >> in an attempt to recover the lost files, but was unsuccessful. >> >> The current issues are: >> >> How do I recover the lost files? > >From a backup? I think they're gone from the source. (But what do I >know) > >> Why does btrfs check --init-csum-tree cause file loss? Is this a bug? > >Seems unlikely. Why do you think the command causes the file loss? Why >do you not think the corruption was already there? And did you read the >DANGEROUS description in the docs? > >> LiveCD information: >> >> Linux ubuntu 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC >> Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux >> >> Thank you for your help. > >As already suggested, you might do better looking elsewhere for help. >Perhaps the linux-btrfs mailing list? >
Re: btrfs check Causes File Corruption
"Longhao.Chen" wrote: > Hello everyone, I use Btrfs as the file system on my laptop. > Yesterday, I was preparing to backup a snapshot to an external hard > drive using btrfs send, and the following error occurred: > > ERROR: send ioctl failed with -5: Input/Output error I use btrfs but don't know much about it :( I certainly know nothing about btrfs send, but the error seems to suggest perhaps an error with the send rather than with reading the source? > I used btrfs scrub to scan the disk, and the result was: Why not btrfs check? > Error summary:csum=1 > > Corrected: 0 > > Uncorrectable: 1 > > Unverified: 0 OK so that sounds like a hardware problem. > Afterwards, I booted a LiveCD and ran: > > btrfs check --init-csum-tree > > During the running process, many outputs similar to this appeared: > > root 1380 inode 5006723 errors 2001, no inode item, link count wrong > unresolved ref dir 1164151 index 1566 namelen 28 name > filetype 1 errors 4, no inode ref > > Then I found that the file in the above had disappeared. > At this point, I immediately backed up all the existing files and > then used: > > btrfs check --repair > > btrfs rescue > > in an attempt to recover the lost files, but was unsuccessful. > > The current issues are: > > How do I recover the lost files? From a backup? I think they're gone from the source. (But what do I know) > Why does btrfs check --init-csum-tree cause file loss? Is this a bug? Seems unlikely. Why do you think the command causes the file loss? Why do you not think the corruption was already there? And did you read the DANGEROUS description in the docs? > LiveCD information: > > Linux ubuntu 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC > Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > > Thank you for your help. As already suggested, you might do better looking elsewhere for help. Perhaps the linux-btrfs mailing list?
Re: btrfs check Causes File Corruption
Thanks for your reply. The disk is a 1TB Samsung SSD with less than 4TiB written, the SMART is completely normal with no errors. I suspect that this error may have been caused by random bit flipping in the memory (DDR4 non-ECC memory). I just want to fix the checksum error (because the file with the checksum error is not important), so I used the command 'btrfs check --init-csum-tree'. 于 2023年8月20日 GMT+08:00 下午8:12:31, piorunz 写到: >On 20/08/2023 12:11, Longhao.Chen wrote: >> Thanks for your reply. I previously read in the btrfs documentation that >> "when repairing the file system, it is advisable to choose a newer kernel", >> so I used Ubuntu's livecd for the repair. > >First of all, did you found the cause of this unrepairable error? >Is HDD failing? What SMART data say? >You should not repair or use medium which is failing, it may cause >further damage. > >-- >With kindest regards, Piotr. > >⢀⣴⠾⠻⢶⣦⠀ >⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system >⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ >⠈⠳⣄ >
Re: btrfs check Causes File Corruption
On 20/08/2023 12:11, Longhao.Chen wrote: Thanks for your reply. I previously read in the btrfs documentation that "when repairing the file system, it is advisable to choose a newer kernel", so I used Ubuntu's livecd for the repair. First of all, did you found the cause of this unrepairable error? Is HDD failing? What SMART data say? You should not repair or use medium which is failing, it may cause further damage. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: btrfs check Causes File Corruption
I'm sorry, because a long time after I sent the first email, I didn't see it in the web archive. I suspected there was a problem during the sending process, so I sent a second one. I apologize for my mistake. >Hello everyone, I use Btrfs as the file system on my laptop. Yesterday, I was >preparing to backup a snapshot to an external hard drive using btrfs send, and >the following error occurred: > >ERROR: send ioctl failed with -5: Input/Output error > >I used btrfs scrub to scan the disk, and the result was: > >Error summary:csum=1 > >Corrected: 0 > >Uncorrectable: 1 > >Unverified: 0 > >Afterwards, I booted a LiveCD and ran: > >btrfs check --init-csum-tree > >During the running process, many outputs similar to this appeared: > >root 1380 inode 5006723 errors 2001, no inode item, link count wrong >unresolved ref dir 1164151 index 1566 namelen 28 name filetype 1 >errors 4, no inode ref > >Then I found that the file in the above had disappeared. At this >point, I immediately backed up all the existing files and then used: > >btrfs check --repair > >btrfs rescue > >in an attempt to recover the lost files, but was unsuccessful. > >The current issues are: > >How do I recover the lost files? > >Why does btrfs check --init-csum-tree cause file loss? Is this a bug? > >LiveCD information: > >Linux ubuntu 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul >13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > >Thank you for your help. >
Re: btrfs check Causes File Corruption
Thanks for your reply. I previously read in the btrfs documentation that "when repairing the file system, it is advisable to choose a newer kernel", so I used Ubuntu's livecd for the repair. >On 20 Aug 2023 17:42 +0800, from longhao.c...@outlook.com (Longhao.Chen): >> LiveCD information: >> >> Linux ubuntu 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC >> Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > >This mailing list is for users of Debian, where current stable ships a >6.1 series kernel. I'm not saying you can't get any suggestions here >(you might), but you will likely have better luck on some forum for >Ubuntu users, as it appears that the corruption (other than possibly a >single initial checksum error, which may have happened for reasons >related or unrelated to any software) occured from within an Ubuntu >environment; or alternatively, some forum focusing on Btrfs, as that >is the part that appears to have caused problems for you. >
Re: btrfs check Causes File Corruption
On Sun, 20 Aug 2023 18:28:56 +0800
"Longhao.Chen" wrote:
Hello Longhao.Chen,
>Hello everyone,
Please be patient. Waiting less that an hour before reposting a question
gains you little.
This is a users mailing list, not a paid for support forum. Anyone here
is volunteering their time. Users with experience of btrfs are a subset
of all users here. Of those users, the ones that have confidence in
their expertise to assist you will be an even smaller subset. Many of
those may not have yet seen your request, never mind had time to
formulate a response.
Thank you.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Where the grass is green and the girls are pretty
Paradise City - Guns 'N' Roses
pgpOCY6VgOGhx.pgp
Description: OpenPGP digital signature
Re: btrfs check Causes File Corruption
On 20 Aug 2023 17:42 +0800, from longhao.c...@outlook.com (Longhao.Chen): > LiveCD information: > > Linux ubuntu 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC > Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux This mailing list is for users of Debian, where current stable ships a 6.1 series kernel. I'm not saying you can't get any suggestions here (you might), but you will likely have better luck on some forum for Ubuntu users, as it appears that the corruption (other than possibly a single initial checksum error, which may have happened for reasons related or unrelated to any software) occured from within an Ubuntu environment; or alternatively, some forum focusing on Btrfs, as that is the part that appears to have caused problems for you. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
