When inspecting the error message with real corruption, the "root=%llu"
always shows "1" (root tree), instead of correct owner.
The problem is that we are getting @root from page->mapping->host, which
points the same btree inode, so we will always get the same root.
This makes the root owner outp
nitpick:
typo in $subject.
Thanks, Anand
--
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
On 2018年01月25日 04:41, ^m'e wrote:
> And here it is:
>
>
> # ./btrfs-debug-tree.static -t 1385 /dev/sdb3 | grep -C 20 30039322 |
In fact, that's only dump tree 1385.
Now we also need the dump of tree 257.
Thanks,
Qu
> tee /mnt/custom/rescue/btrfs-re
On 2018年01月25日 03:00, ^m'e wrote:
> The complete check:
>
> Checking filesystem on /dev/sdb3
> UUID: de1723e2-150c-4448-bb36-be14d7d96093
> ERROR: extent[64368619520, 524288] referencer count mismatch (root:
> 257, owner: 7804556, offset: 212992) wanted: 1, have: 0
> ERROR: data extent[186235289
On Wed, Jan 24, 2018 at 5:30 AM, Austin S. Hemmelgarn
wrote:
>> APFS is really vague on this front, it may be checksumming metadata,
>> it's not checksumming data and with no option to. Apple proposes their
>> branded storage devices do not return bogus data. OK so then why
>> checksum the metada
Claes Fransson posted on Wed, 24 Jan 2018 20:44:33 +0100 as excerpted:
> So, I have now some results from the PassMark Memtest86! I let the
> default automatic tests run for about 19 hours and 16 passes. It
> reported zero "Errors", but 4 lines of "[Note] RAM may be vulnerable to
> high frequency
On 01/24/2018 07:54 PM, waxhead wrote:
> Hans van Kranenburg wrote:
>> On 01/23/2018 08:51 PM, waxhead wrote:
>>> Nikolay Borisov wrote:
On 23.01.2018 16:20, Hans van Kranenburg wrote:
>>
>> [...]
>>
>
> We also had a discussion about the "backup roots" that are stored
> besides th
And here it is:
# ./btrfs-debug-tree.static -t 1385 /dev/sdb3 | grep -C 20 30039322 |
tee /mnt/custom/rescue/btrfs-recovery/btrfs-debug.30039322.2.log
location key (30037910 INODE_ITEM 0) type DIR
transid 136248 data_len 0 name_len 3
On Jan 24, 2018 01:31, "Chris Murphy" wrote:
On Tue, Jan 23, 2018 at 11:13 AM, Claes Fransson
wrote:
> I haven't noticed before that there is actually RAM-modules from
> different vendors in the laptop. One 8GB by Samsung, and one 4GB by
> Kingston!
If they have the correct tolerances, I don't
The complete check:
Checking filesystem on /dev/sdb3
UUID: de1723e2-150c-4448-bb36-be14d7d96093
ERROR: extent[64368619520, 524288] referencer count mismatch (root:
257, owner: 7804556, offset: 212992) wanted: 1, have: 0
ERROR: data extent[1862352896 425984] backref lost
ERROR: data extent[18864537
Hans van Kranenburg wrote:
On 01/23/2018 08:51 PM, waxhead wrote:
Nikolay Borisov wrote:
On 23.01.2018 16:20, Hans van Kranenburg wrote:
[...]
We also had a discussion about the "backup roots" that are stored
besides the superblock, and that they are "better than nothing" to help
maybe rec
On 01/22/2018 04:17 PM, Sebastian Ochmann wrote:
> Hello,
>
> I attached to the ffmpeg-mux process for a little while and pasted the
> result here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_XHaMLX8z&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=9QPtTAxcitoznaWRKKHoEQ&m=IkofqwZ_
On Tue, Jan 23, 2018 at 02:46:53PM +0200, Nikolay Borisov wrote:
> Instead of manually fiddling with the state of the task
> (RUNNING->INTERRUPTIBLE->RUNNING) again just use
> schedule_timeout_interruptible
> which adjusts the task state as needed. No functional changes.
>
> Signed-off-by: Nikola
My bad, forgot to check out the correct branch. Recloned, compiled and
fixed. Then rechecking:
---
# btrfs check --mode=lowmem /dev/sdb3
Checking filesystem on /dev/sdb3
UUID: de1723e2-150c-4448-bb36-be14d7d96093
checking extents
ERROR: exten
On 2018年01月24日 19:57, ^m'e wrote:
> Thanks Qu!
>
> I did it (had to add 'progs_extra' to the 'static' make target...),
> but it looks like there's something missing:
Did you check out the branch called "dirty_fix"?
Thanks,
Qu
>
> -
>
On 2018-01-23 19:44, Chris Murphy wrote:
On Tue, Jan 23, 2018 at 5:51 AM, Austin S. Hemmelgarn
wrote:
This is extremely important to understand. BTRFS and ZFS are essentially
the only filesystems available on Linux that actually validate things enough
to notice this reliably (ReFS on Windows
Thanks Qu!
I did it (had to add 'progs_extra' to the 'static' make target...),
but it looks like there's something missing:
-
# ./btrfs-corrupt-block.static -X /dev/sdb3
./btrfs-corrupt-block.static: invalid option -- 'X'
usage: btrfs-co
Here is the super dirty tricky fix (and less deadly now).
https://github.com/adam900710/btrfs-progs/tree/dirty_fix
Please compile the branch and run:
# ./btrfs-corrupt-block -X
Where must be unmounted, the original btrfs-corrupt-block tool
doesn't have mount check, and I'm too lazy to add suc
On 24.01.2018 04:38, Qu Wenruo wrote:
> Commit 0b2161becf8e ("btrfs-progs: mkfs: Prevent temporary system chunk
> to use space in reserved 1M range") changed the hard-coded temporary
> chunk layout to avoid the first 1M.
>
> However this also affects btrfs_min_dev_size() which still assume
> tem
On 24.01.2018 04:30, Qu Wenruo wrote:
> @chunk_objectid of btrfs_make_block_group() function is always fixed to
> BTRFS_FIRST_FREE_OBJECTID, so there is no need to pass it as parameter
> explicitly.
>
> Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
> ---
> v2:
> Rebase to devel bran
Qu Wenruo wrote on 2018-01-24 09:49:
> Sorry for the late reply, I was off yesterday.
>
No problem :-)
Booted normally today, system up, but see this (I forgot to stop the snapshot
cron task...)
[ 115.127961] BTRFS error (device sdb3): Send: inconsistent snapshot, found
deleted reference for
Ok, so I ended with btrfs restore, seems that all (or most important)
files were restored.
Now looking for another reliable filesystem which will not unrecoverably
die on power outage.
msk
Dňa 22. 1. 2018 o 10:14 Zatkovský Dušan napísal(a):
Hi.
Badblocks finished on both disks with no err
Sorry for the late reply, I was off yesterday.
On 2018年01月22日 23:04, ^m'e wrote:
> Thanks for the quick reply, Qu!
>
> I forgot to say that I see weird characters in the btrfs check repair
> in lines "ERROR: DIR_ITEM... name ..." output. Although that can be
> due to corruption, I seem to remembe
Mathhew,
Just a minor question.
On Wed, 2018-01-17 at 12:20 -0800, Matthew Wilcox wrote:
> This is a direct replacement for struct radix_tree_root. Some of the
> struct members have changed name; convert those, and use a #define so
> that radix_tree users continue to work without change.
>
> Si
24 matches
Mail list logo
