On Mon, Dec 24, 2018 at 4:31 AM Peter Chant wrote:
>
> Just done that:
> bash-4.3# btrfs-image -ss -c9 -t4 /dev/sdd2
> /mnt/backup/btrfs_issue_dec_2018/btrfs_root_image_error_20181224.img
> WARNING: cannot find a hash collision for '..', generating garbage, it
> won't match indexes
normal for so
On 2018/12/24 下午9:52, Tomáš Metelka wrote:
> On 24. 12. 18 14:02, Qu Wenruo wrote:
>> btrfs check --readonly output please.
>>
>> btrfs check --readonly is always the most reliable and detailed output
>> for any possible recovery.
>
> This is very weird because it prints only:
> ERROR: cannot op
On 24. 12. 18 14:02, Qu Wenruo wrote:
btrfs check --readonly output please.
btrfs check --readonly is always the most reliable and detailed output
for any possible recovery.
This is very weird because it prints only:
ERROR: cannot open file system
I've tried also "btrfs check -r 75152310272"
On 2018/12/24 下午8:48, Tomáš Metelka wrote:
> Hi Qu,
>
> just 1 curious question (maybe 2) about your statement "log_root is 0":
>
> What does it mean when log_root is non-zero?
This means there are some dirty log, namely caused by fsync().
You could consider log tree as some kind of journal u
Hi Qu,
just 1 curious question (maybe 2) about your statement "log_root is 0":
What does it mean when log_root is non-zero? Because I have similar
problem (unmountable FS ... I don't know how much but I know there's
corrupted 2 subsequent items in chunk tree node) and when I have made
"btrfs
On 2018/12/24 下午7:31, Peter Chant wrote:
> On 12/24/18 12:58 AM, Chris Murphy wrote:
>> On Sat, Dec 22, 2018 at 10:22 AM Peter Chant wrote:
>>
>>> btrfs rescue super -v /dev/sdb2
>> ...
>>> All supers are valid, no need to recover
>>>
>>>
>>> btrfs insp dump-s -f
>> ...
>>> generation
On 12/24/18 2:00 AM, Qu Wenruo wrote:
> I'd recommend to use "btrfs check -r 1113911951360" to verify if it's
> only superblock generation corrupted.
(cancelled "btrfs-image -ss -c9 -t4 -w /dev/sdd2
/mnt/backup/btrfs_issue_dec_2018/btrfs_root_image_error_with_w_20181224.img"
as it said it was g
On 12/24/18 12:58 AM, Chris Murphy wrote:
> On Sat, Dec 22, 2018 at 10:22 AM Peter Chant wrote:
>
>> btrfs rescue super -v /dev/sdb2
> ...
>> All supers are valid, no need to recover
>>
>>
>> btrfs insp dump-s -f
> ...
>> generation 7937947
> ...
>> backup 0:
>>
On 2018/12/24 上午8:58, Chris Murphy wrote:
> On Sat, Dec 22, 2018 at 10:22 AM Peter Chant wrote:
>
>> btrfs rescue super -v /dev/sdb2
> ...
>> All supers are valid, no need to recover
>>
>>
>> btrfs insp dump-s -f
> ...
>> generation 7937947
> ...
>> backup 0:
>>
On Sat, Dec 22, 2018 at 10:22 AM Peter Chant wrote:
> btrfs rescue super -v /dev/sdb2
...
> All supers are valid, no need to recover
>
>
> btrfs insp dump-s -f
...
> generation 7937947
...
> backup 0:
> backup_tree_root: 1113909100544 gen: 7937935
On 12/21/2018 10:25 PM, Chris Murphy wrote:
> On Thu, Dec 20, 2018 at 3:23 PM Peter Chant wrote:
>>
>> I managed to break my root partition today. Playing with GPU
>> passthrough to a second graphics card, unsuccessfully, I suspect lead to
>> some lockups and/or unclean mounts.
>
> Should not ma
On Thu, Dec 20, 2018 at 3:23 PM Peter Chant wrote:
>
> I managed to break my root partition today. Playing with GPU
> passthrough to a second graphics card, unsuccessfully, I suspect lead to
> some lockups and/or unclean mounts.
Should not matter, in theory.
> I've Googled a bit and tried a nu
12 matches
Mail list logo
