Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

2015-12-15 Thread David Sterba 
On Tue, Dec 08, 2015 at 11:06:28AM +0900, Naohiro Aota wrote:
> On Tue, Dec 8, 2015 at 12:35 AM, David Sterba  wrote:
> > On Mon, Dec 07, 2015 at 11:59:19AM +0900, Naohiro Aota wrote:
> >> > But I only see the first 2 patches in maillist...
> >> > The last test case seems missing?
> >>
> >> Maybe, the last patch is too large to post to the list? Even it get
> >> smaller, 130260 bytes seems to be a bit large.
> >>
> >> How should I handle this? Put my repo somewhere and wait a maintainer
> >> to pull it?
> >
> > Please send it to me directly. The image will be available in
> > btrfs-progs git and we don't necessarily need the copy in the
> > mailinglist.
> 
> Sure. I'll send it to you.

Applied, thanks.
--
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/3] btrfs-progs: fix file restore to lost+found bug

2015-12-07 Thread David Sterba 
On Mon, Dec 07, 2015 at 11:59:19AM +0900, Naohiro Aota wrote:
> > But I only see the first 2 patches in maillist...
> > The last test case seems missing?
> 
> Maybe, the last patch is too large to post to the list? Even it get
> smaller, 130260 bytes seems to be a bit large.
> 
> How should I handle this? Put my repo somewhere and wait a maintainer
> to pull it?

Please send it to me directly. The image will be available in
btrfs-progs git and we don't necessarily need the copy in the
mailinglist.
--
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/3] btrfs-progs: fix file restore to lost+found bug

2015-12-07 Thread Naohiro Aota 
On Tue, Dec 8, 2015 at 12:35 AM, David Sterba  wrote:
> On Mon, Dec 07, 2015 at 11:59:19AM +0900, Naohiro Aota wrote:
>> > But I only see the first 2 patches in maillist...
>> > The last test case seems missing?
>>
>> Maybe, the last patch is too large to post to the list? Even it get
>> smaller, 130260 bytes seems to be a bit large.
>>
>> How should I handle this? Put my repo somewhere and wait a maintainer
>> to pull it?
>
> Please send it to me directly. The image will be available in
> btrfs-progs git and we don't necessarily need the copy in the
> mailinglist.

Sure. I'll send it to you.
--
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/3] btrfs-progs: fix file restore to lost+found bug

2015-12-06 Thread Qu Wenruo 



Naohiro Aota wrote on 2015/12/07 11:59 +0900:

On Sat, Dec 5, 2015 at 10:35 AM, Qu Wenruo  wrote:



On 12/04/2015 01:37 PM, Naohiro Aota wrote:


This series address an issue of btrfsck to restore infinite number of
same file into `lost+found' directory. The issue occur on a file which
is linked from two different directory A and B. If links from dir A is
corrupted and links from dir B is kept valid, btrfsck won't stop
creating a file in lost+found like this:

-
Moving file 'file.del.51' to 'lost+found' dir since it has no valid
backref
Fixed the nlink of inode 1876
Trying to rebuild inode:1877
Moving file 'del' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1877
Can't get file name for inode 1876, using '1876' as fallback
Moving file '1876' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Can't get file name for inode 1876, using '1876' as fallback
Moving file '1876.1876' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
(snip)
Moving file
'1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876'
to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Can't get file name for inode 1876, using '1876' as fallback
Can't get file name for inode 1876, using '1876' as fallback
Can't get file name for inode 1876, using '1876' as fallback
-

The problem is early release of inode backrefs. The release prevents
`reset_nlink()' to add back valid backrefs to an inode. In the result,
the following results occur:

0. btrfsck scan a FS tree
1. It finds valid links and invalid links (some links are lost)
2. All valid links are released
3. btrfsck detects found_links != nlink
4. reset_nlink() reset nlink to 0
5. No valid links are restored (thus still nlink = 0)
6. The file is restored to lost+found since nlink == 0 (now, nlink = 1)
7. btrfsck rescan the FS tree
8. It finds `found_links' = #valid_links+1 (in lost+found) and nlink = 1
9. again all valid links are lost, and restore to lost+found



Right, that's one case I missed in the repair code.

Thanks for the fix.


Thanks for the review.





The first patch add clean up code to the test. It umount test
directory on failure path. The second patch fix the above problem. And
the last patch extend the test to check a case of multiple-linked file
corruption.



But I only see the first 2 patches in maillist...
The last test case seems missing?


Maybe, the last patch is too large to post to the list? Even it get
smaller, 130260 bytes seems to be a bit large.

How should I handle this? Put my repo somewhere and wait a maintainer
to pull it?


One idea is to use btrfs-image to dump the image (if it is still able to 
trigger the bug).

Btrfs-image dump is much more efficient than raw dump.

Or as you mentioned, put the repo somewhere like github, and send pull 
request to David, mentioning the patch is already sent to maillist.


Thanks,
Qu





Thanks,
Qu



--
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




--
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





--
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/3] btrfs-progs: fix file restore to lost+found bug

2015-12-06 Thread Naohiro Aota 
On Sat, Dec 5, 2015 at 10:35 AM, Qu Wenruo  wrote:
>
>
> On 12/04/2015 01:37 PM, Naohiro Aota wrote:
>>
>> This series address an issue of btrfsck to restore infinite number of
>> same file into `lost+found' directory. The issue occur on a file which
>> is linked from two different directory A and B. If links from dir A is
>> corrupted and links from dir B is kept valid, btrfsck won't stop
>> creating a file in lost+found like this:
>>
>> -
>> Moving file 'file.del.51' to 'lost+found' dir since it has no valid
>> backref
>> Fixed the nlink of inode 1876
>> Trying to rebuild inode:1877
>> Moving file 'del' to 'lost+found' dir since it has no valid backref
>> Fixed the nlink of inode 1877
>> Can't get file name for inode 1876, using '1876' as fallback
>> Moving file '1876' to 'lost+found' dir since it has no valid backref
>> Fixed the nlink of inode 1876
>> Can't get file name for inode 1876, using '1876' as fallback
>> Moving file '1876.1876' to 'lost+found' dir since it has no valid backref
>> Fixed the nlink of inode 1876
>> (snip)
>> Moving file
>> '1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876'
>> to 'lost+found' dir since it has no valid backref
>> Fixed the nlink of inode 1876
>> Can't get file name for inode 1876, using '1876' as fallback
>> Can't get file name for inode 1876, using '1876' as fallback
>> Can't get file name for inode 1876, using '1876' as fallback
>> -
>>
>> The problem is early release of inode backrefs. The release prevents
>> `reset_nlink()' to add back valid backrefs to an inode. In the result,
>> the following results occur:
>>
>> 0. btrfsck scan a FS tree
>> 1. It finds valid links and invalid links (some links are lost)
>> 2. All valid links are released
>> 3. btrfsck detects found_links != nlink
>> 4. reset_nlink() reset nlink to 0
>> 5. No valid links are restored (thus still nlink = 0)
>> 6. The file is restored to lost+found since nlink == 0 (now, nlink = 1)
>> 7. btrfsck rescan the FS tree
>> 8. It finds `found_links' = #valid_links+1 (in lost+found) and nlink = 1
>> 9. again all valid links are lost, and restore to lost+found
>
>
> Right, that's one case I missed in the repair code.
>
> Thanks for the fix.

Thanks for the review.

>
>>
>> The first patch add clean up code to the test. It umount test
>> directory on failure path. The second patch fix the above problem. And
>> the last patch extend the test to check a case of multiple-linked file
>> corruption.
>
>
> But I only see the first 2 patches in maillist...
> The last test case seems missing?

Maybe, the last patch is too large to post to the list? Even it get
smaller, 130260 bytes seems to be a bit large.

How should I handle this? Put my repo somewhere and wait a maintainer
to pull it?

>
> Thanks,
> Qu
>
>>
>> --
>> 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
>>
>
--
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

[PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

2015-12-04 Thread Naohiro Aota 
This series address an issue of btrfsck to restore infinite number of
same file into `lost+found' directory. The issue occur on a file which
is linked from two different directory A and B. If links from dir A is
corrupted and links from dir B is kept valid, btrfsck won't stop
creating a file in lost+found like this:

-
Moving file 'file.del.51' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Trying to rebuild inode:1877
Moving file 'del' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1877
Can't get file name for inode 1876, using '1876' as fallback
Moving file '1876' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Can't get file name for inode 1876, using '1876' as fallback
Moving file '1876.1876' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
(snip)
Moving file 
'1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876'
 to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Can't get file name for inode 1876, using '1876' as fallback
Can't get file name for inode 1876, using '1876' as fallback
Can't get file name for inode 1876, using '1876' as fallback
-

The problem is early release of inode backrefs. The release prevents
`reset_nlink()' to add back valid backrefs to an inode. In the result,
the following results occur:

0. btrfsck scan a FS tree
1. It finds valid links and invalid links (some links are lost)
2. All valid links are released
3. btrfsck detects found_links != nlink
4. reset_nlink() reset nlink to 0
5. No valid links are restored (thus still nlink = 0)
6. The file is restored to lost+found since nlink == 0 (now, nlink = 1)
7. btrfsck rescan the FS tree
8. It finds `found_links' = #valid_links+1 (in lost+found) and nlink = 1
9. again all valid links are lost, and restore to lost+found

The first patch add clean up code to the test. It umount test
directory on failure path. The second patch fix the above problem. And
the last patch extend the test to check a case of multiple-linked file
corruption.

--
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/3] btrfs-progs: fix file restore to lost+found bug

2015-12-04 Thread Qu Wenruo 



On 12/04/2015 01:37 PM, Naohiro Aota wrote:

This series address an issue of btrfsck to restore infinite number of
same file into `lost+found' directory. The issue occur on a file which
is linked from two different directory A and B. If links from dir A is
corrupted and links from dir B is kept valid, btrfsck won't stop
creating a file in lost+found like this:

-
Moving file 'file.del.51' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Trying to rebuild inode:1877
Moving file 'del' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1877
Can't get file name for inode 1876, using '1876' as fallback
Moving file '1876' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Can't get file name for inode 1876, using '1876' as fallback
Moving file '1876.1876' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
(snip)
Moving file 
'1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876.1876'
 to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 1876
Can't get file name for inode 1876, using '1876' as fallback
Can't get file name for inode 1876, using '1876' as fallback
Can't get file name for inode 1876, using '1876' as fallback
-

The problem is early release of inode backrefs. The release prevents
`reset_nlink()' to add back valid backrefs to an inode. In the result,
the following results occur:

0. btrfsck scan a FS tree
1. It finds valid links and invalid links (some links are lost)
2. All valid links are released
3. btrfsck detects found_links != nlink
4. reset_nlink() reset nlink to 0
5. No valid links are restored (thus still nlink = 0)
6. The file is restored to lost+found since nlink == 0 (now, nlink = 1)
7. btrfsck rescan the FS tree
8. It finds `found_links' = #valid_links+1 (in lost+found) and nlink = 1
9. again all valid links are lost, and restore to lost+found


Right, that's one case I missed in the repair code.

Thanks for the fix.



The first patch add clean up code to the test. It umount test
directory on failure path. The second patch fix the above problem. And
the last patch extend the test to check a case of multiple-linked file
corruption.


But I only see the first 2 patches in maillist...
The last test case seems missing?

Thanks,
Qu



--
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


--
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