Ok then, many thanks.
In a letter from Friday, July 14, 2017 15:41:22 MSK user Qu Wenruo wrote:
>
> On 2017年07月14日 20:26, Filippe LeMarchand wrote:
> > So, my options are
> > a) Delete and re-create sobvolume
> > b) Try btrfs check --repair --mode original (if original mode is default,
> > it
On 2017年07月14日 20:26, Filippe LeMarchand wrote:
So, my options are
a) Delete and re-create sobvolume
b) Try btrfs check --repair --mode original (if original mode is default, it
already didn't help)
Then --repair doesn't help now.
c) Do nothing and wait for further update
Further update
So, my options are
a) Delete and re-create sobvolume
b) Try btrfs check --repair --mode original (if original mode is default, it
already didn't help)
c) Do nothing and wait for further update
?
In a letter from Friday, July 14, 2017 15:11:05 MSK user Qu Wenruo wrote:
>
> On 2017年07月14日 20:04,
On 2017年07月14日 20:04, Filippe LeMarchand wrote:
Currently possible solution may be deleting the whole subvolume.
Can btrfs send (to external drive) and then btrfs receive back fix it? Or
should I use simple cp/rsync?
You could try if you have backup.
Personally speaking, I'm not sure if
> Currently possible solution may be deleting the whole subvolume.
Can btrfs send (to external drive) and then btrfs receive back fix it? Or
should I use simple cp/rsync?
> If you have full backup, then you could try it.
It is my root subvolume (sensitive data is on other ones), thus it is
On 2017年07月14日 18:12, Filippe LeMarchand wrote:
First "rm" on deprecated.txt worked, but file is still there. Neither the file,
nor its parent directory cannot be deleted:
$ sudo rm /usr/share/doc/packages/util-linux/deprecated.txt
rm: cannot remove
First "rm" on deprecated.txt worked, but file is still there. Neither the file,
nor its parent directory cannot be deleted:
$ sudo rm /usr/share/doc/packages/util-linux/deprecated.txt
rm: cannot remove '/usr/share/doc/packages/util-linux/deprecated.txt': No such
file or directory
$ sudo rm -rf
Thanks for your dump.
We're clear what is the direct cause of the problem.
It's one corrupted DIR_ITEM causing the problem.
And further more, original mode btrfs check can't detect it, and we will
fix it soon.
The corrupted DIR_ITEM is as the following:
item 72 key (79177 DIR_ITEM
Done, files added to same GDrive folder with corresponding names.
If it matters, subvol 4546 is my root filesystem (r/w snapshot created with
snapper rollback), and 5134 is its snapshot.
In a letter dated Wednesday, July 12, 2017 15:44:52 MSK user Qu Wenruo wrote:
>
> On 2017年07月12日 19:12,
On 2017年07月12日 19:12, Filippe LeMarchand wrote:
Maybe something wrong in grep happened which skip "(79177" ?
Yes, my bad. Now I used grep -E "\(79177| 79177" pattern, file on GDrive
updated.
It looks much better, thanks.
And btrfs check --mode=lowmem gives this:
checking extents
ERROR:
> Maybe something wrong in grep happened which skip "(79177" ?
Yes, my bad. Now I used grep -E "\(79177| 79177" pattern, file on GDrive
updated.
And btrfs check --mode=lowmem gives this:
checking extents
ERROR: extent[1609877700608, 94208] referencer count mismatch (root: 260,
owner: 61720,
Sorry for the late reply.
After investigating the dumps, I found the output is quite strange.
1) Mismatching output.
In "btrfs-debug-tree-grep-79177.txt" I found only 79177 as offset for
INODE_REF is here, while 79177 as objectid for DIR_ITEM/DIR_INDEX is not
here at all.
While in
Sure, here it is:
https://drive.google.com/drive/folders/0B1ax9Am81gx9YjJBVVA0LXRHeGc
In a letter dated Tuesday, July 4, 2017 16:16:36 MSK user Lu Fengqi wrote:
> On Mon, Jul 03, 2017 at 08:34:52AM +0800, Qu Wenruo wrote:
> >
> >
> >At 07/01/2017 07:59 PM, Filippe LeMarchand wrote:
> >> Hello
On Mon, Jul 03, 2017 at 08:34:52AM +0800, Qu Wenruo wrote:
>
>
>At 07/01/2017 07:59 PM, Filippe LeMarchand wrote:
>> Hello everyone.
>>
>> I have an btrfs root partition on Intel 530 ssd, which mounts without errors
>> and seem to work fine,
>> but `btrfs check` gives me foloowing output (and
At 07/01/2017 07:59 PM, Filippe LeMarchand wrote:
Hello everyone.
I have an btrfs root partition on Intel 530 ssd, which mounts without errors
and seem to work fine,
but `btrfs check` gives me foloowing output (and --repair doesn't remove
errors):
enabling repair mode
Checking filesystem
Hello everyone.
I have an btrfs root partition on Intel 530 ssd, which mounts without errors
and seem to work fine,
but `btrfs check` gives me foloowing output (and --repair doesn't remove
errors):
enabling repair mode
Checking filesystem on /dev/sda2
UUID: 12c84aa3-ce65-4390-807e-a72cc8a7445e
16 matches
Mail list logo
