Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

2017-08-01 0:39 GMT+03:00 Ivan Sizov <sivan...@gmail.com>: > 2017-08-01 0:17 GMT+03:00 Marc MERLIN <m...@merlins.org>: >> On Tue, Aug 01, 2017 at 12:07:14AM +0300, Ivan Sizov wrote: >>> 2017-07-09 10:57 GMT+03:00 Martin Steigerwald <mar...@lichtvoll.de>: >&

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

2017-08-01 0:17 GMT+03:00 Marc MERLIN <m...@merlins.org>: > On Tue, Aug 01, 2017 at 12:07:14AM +0300, Ivan Sizov wrote: >> 2017-07-09 10:57 GMT+03:00 Martin Steigerwald <mar...@lichtvoll.de>: >> > Hello Marc. >> > >> > Marc MERLIN - 08.07.17, 21

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

fs-ref-backpointer-mismatches-backref-missing/369275 If an additional debug info is needed, I'm ready to provide it. -- Ivan Sizov -- 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

Re: "Unable to find ref byte nr ...." (4.11 somehow fishy?)

/0x90 > [ 625.657545] ret_from_fork+0x2c/0x40 > [ 625.657546] ---[ end trace 1c4d5dd9396052af ]--- > [ 625.657548] BTRFS: error (device dm-1) in __btrfs_free_extent:6942: > errno=-2 No such entry > [ 625.657550] BTRFS info (device dm-1): forced readonly > [ 625.657553] BTRFS:

Re: What are the typical usecase of "btrfs check --init-extent-tree"?

Small clarification after reading journal: errors stats weren't changed on sda since December, but READ error count was increased on sdc (especially in May, when I first noticed problems) and sdb. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: What are the typical usecase of "btrfs check --init-extent-tree"?

pid "check --repair" attempts corrupted FS internals heavily. Can I just remove sda from RAID-1 and run rebalance? 2017-07-27 17:02 GMT+03:00 Ivan Sizov <sivan...@gmail.com>: > My RAID-1 FS have multiple "backpointer mismatch" errors. "btrfs check > --repair"

What are the typical usecase of "btrfs check --init-extent-tree"?

nit-extent-tree" deal with backref problems? Will those backrefs completely reconstructed? Can similar "backref not found" and "backpointer mismatched" errors have very different causes and different fix scenarios? -- Ivan Sizov -- To unsubscribe from this list: send the line

Re: Help on using linux-btrfs mailing list please

> your own post that no-one has yet replied to? Yes, exactly. -- Ivan Sizov -- 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

Re: Help on using linux-btrfs mailing list please

; folder, you can, of course, follow one of these examples. But I didn't face with such situation ever. -- Ivan Sizov -- 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

Re: Help on using linux-btrfs mailing list please

uot;TO: mailing list" only, without any other addresses. At least I used to initiate posts in such way. -- Ivan Sizov -- 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

Re: Help on using linux-btrfs mailing list please

put respective addresses, eg: TO: CC: BCC: You need to put a person to whom you reply in "TO" field and mailing list in "CC" field. -- Ivan Sizov -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...

Re: Help on using linux-btrfs mailing list please

ide for > using this mailing list? > > Thanks > > Jesse > -- > 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

Re: [PATCH 0/6] add sanity check for extent inline ref type

2017-06-02 1:57 GMT+03:00 Liu Bo <bo.li@oracle.com>: > On Thu, Jun 01, 2017 at 11:26:26PM +0300, Ivan Sizov wrote: >> 2017-06-01 20:35 GMT+03:00 Liu Bo <bo.li@oracle.com>: >> > After I went through the output of leaf's content, most parts of the >> >

Re: [PATCH 0/6] add sanity check for extent inline ref type

in order to determine which files are corrupted? What are proper options to run fsck with? -- Ivan Sizov -- 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

Re: [PATCH 0/6] add sanity check for extent inline ref type

2017-05-30 21:02 GMT+03:00 Liu Bo <bo.li@oracle.com>: > On Tue, May 30, 2017 at 05:05:09PM +0300, Ivan Sizov wrote: >> 2017-05-26 3:26 GMT+03:00 Liu Bo <bo.li@oracle.com>: >> >Patch 6 adds scrub support to detect the corruption, so users can be >> not

Re: [PATCH 0/6] add sanity check for extent inline ref type

2017-05-26 3:26 GMT+03:00 Liu Bo : >Patch 6 adds scrub support to detect the corruption, so users can be noticed when they do scrub on a regular basis. >I'm not sure in the real world what may result in this corruption I've caught this type of corruption in the wild. The big

Re: Can't remount a BTRFS partition read write after a drive failure

ur disk's USB-SATA controller is almost dead. You shouldn't further use it with USB because this lead to data corruption. Detach HDD from case and plug directly to a SATA port or replace the controller. -- Ivan Sizov -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs"

Re: Strange behavior after "rm -rf //"

n Tue, 09 Aug 2016 11:10:08 -0600 as excerpted: > >> On Mon, Aug 8, 2016 at 12:38 PM, Ivan Sizov <sivan...@gmail.com> wrote: >>> 2016-08-08 20:13 GMT+03:00 Chris Murphy <li...@colorremedies.com>: >>>> Just a wild guess, the deletions may be in the tree log a

Re: Strange behavior after "rm -rf //"

2016-08-08 21:52 GMT+03:00 Hugo Mills <h...@carfax.org.uk>: > On Mon, Aug 08, 2016 at 09:38:28PM +0300, Ivan Sizov wrote: >> P.S. IMHO, log replay by default is a quite dangerous thing. I didn't >> know about that change and I could lose all files if the live USB had >&

Re: Strange behavior after "rm -rf //"

. Certainly, I'll make an rsync diff between two-week-ago snapshot and the current FS state. But it will better if in-place recover without backup is possible. P.S. IMHO, log replay by default is a quite dangerous thing. I didn't know about that change and I could lose all files if the live USB had 4.6

Strange behavior after "rm -rf //"

a strange thing was discovered. Deleted files are present when I "mount -r" the disk, but btrfs-restore tells they are deleted ("We have looped trying to restore files too many times to be making progress"). What does it mean? Will those files be deleted after RW

Determine the creation time of a root tree

Is there a way to know when the root tree or generation was created? btrfs-find-root doesn't have such option. -- Ivan Sizov (SIvan) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo inf

Re: Will "btrfs check --repair" fix the mounting problem?

on 459292672 wanted 21148 found 21153 Ignoring transid failure bad block 459292672 Errors found in extent allocation tree or chunk allocation parent transid verify failed on 459292672 wanted 21148 found 21153 Should I ignore those errors and run btrfsck --repair? Or --init-extent-tree is needed? -- Ivan

Re: Will "btrfs check --repair" fix the mounting problem?

ing of the found root or it isn't safe? > +1 for the advice if you just want to use back up things and get back to > normal life. I already backed up the most important data (the whole disk space is 1,82 TB). But I want to solve this strange problem. -- Ivan Sizov -- 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

Determine is file a reflink or not

Is there a way to view the CoW structure, e.g. to know is file just a reflink or it was modified? I copied many files from snapshot with --reflink=always I and want to know which files was modified since the copying. Calculating hashsums seems to be too long thing. -- Ivan Sizov

Re: Will "btrfs check --repair" fix the mounting problem?

2015-12-11 21:24 GMT+03:00 Chris Murphy : > I would not repair it if the risk of it getting worse is bad for your data. > > Note the wiki says this feature is not well tested and is reported to > not work reliably. >

Will "btrfs check --repair" fix the mounting problem?

Btrfs crashes in few seconds after mounting RW. If it's important: the volume was converted from ext4. "ext2_saved" subvolume still presents. dmesg: [ 625.998387] BTRFS info (device sda1): disk space caching is enabled [ 625.998392] BTRFS: has skinny extents [ 627.727708] BTRFS: checking UUID