Hi,
As many have already known, "btrfs check" is a memory eater.
The problem is, btrfsck checks extent tree in a very comprehensive method.
1) Create extent_ref for each extent item with backref
2) Iterate all other trees to add extent ref
3) If one extent_ref with all ref/backref matches, it's
Add new btrfsck option, '--chunk-root', to specify chunk root bytenr.And
allow open_ctree_fs_info() function accept chunk_root_bytenr to override
the bytenr in superblock.This will be mainly used when chunk tree
corruption.
Signed-off-by: Lu Fengqi
---
btrfs-debug-tree.c | 2 +-
btrfs-find-root
Add new btrfsck option, '--chunk-root', to specify chunk root bytenr.Modify
open_ctree_fs_info() function to accept chunk_root_bytenr to override the
bytenr in superblock.
Lu Fengqi (1):
btrfs-progs: Add new option for specify chunk root bytenr
btrfs-debug-tree.c | 2 +-
btrfs-find-root.c
On 2016/03/07 12:05, Satoru Takeuchi wrote:
> - It's better to show a warning message for the exceptional case
>that one of objectid (in most case, inode number) reaches its
>highest value. Show this message only once to avoid filling
>dmesg with it.
> - EOVERFLOW is more proper return
- It's better to show a warning message for the exceptional case
that one of objectid (in most case, inode number) reaches its
highest value. Show this message only once to avoid filling
dmesg with it.
- EOVERFLOW is more proper return value for this case.
ENOSPC is for "No space left on de
On Sun, Mar 6, 2016 at 3:27 PM, Rich Freeman wrote:
> On Sun, Mar 6, 2016 at 4:07 PM, Chris Murphy wrote:
>> On Sun, Mar 6, 2016 at 5:01 AM, Rich Freeman wrote:
>>
>>> I think it depends on how you define "old." I think that 3.18.28
>>> would be fine as it is a supported longterm.
>>
>> For rai
Hi Filipe,
On 2016/03/04 18:28, Filipe Manana wrote:
On Fri, Mar 4, 2016 at 2:37 AM, Satoru Takeuchi
wrote:
- It's better to show a warning message for the exceptional case
that one of highest objectid (in most case, inode number)
reaches its max value, BTRFS_LAST_FREE_OBJECTID. Show thi
On Sun, Mar 6, 2016 at 4:07 PM, Chris Murphy wrote:
> On Sun, Mar 6, 2016 at 5:01 AM, Rich Freeman wrote:
>
>> I think it depends on how you define "old." I think that 3.18.28
>> would be fine as it is a supported longterm.
>
> For raid56? I disagree. There were substantial raid56 code changes i
Good catch,
Reviewed-by: Darrick J. Wong
--D
On Sat, Mar 05, 2016 at 12:25:02PM -0800, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
>
> diff --git a/tests/xfs/209 b/tests/xfs/209
> index cecd9c7..9bf1f12 100755
> --- a/tests/xfs/209
> +++ b/tests/xfs/209
> @@ -73,7 +73,7 @@ echo
On Sun, Mar 6, 2016 at 5:01 AM, Rich Freeman wrote:
> I think it depends on how you define "old." I think that 3.18.28
> would be fine as it is a supported longterm.
For raid56? I disagree. There were substantial raid56 code changes in
3.19 that were not backported to 3.18.
https://git.kernel.o
On Sun, Mar 6, 2016 at 1:27 PM, Chris Murphy wrote:
> So if it were me, I'd gather all possible data, including complete,
> not trimmed, logs.
Also include in the bug, the balance script being used. It might be a
contributing factor.
I wonder if the ENOSPC is happening just prior to the point w
On Sat, Mar 5, 2016 at 11:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
>
>> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>
>>> Something is happening with the usage of this file system that's out of
>>> the ordinar
Rich Freeman posted on Sun, 06 Mar 2016 07:01:00 -0500 as excerpted:
> On Tue, Mar 1, 2016 at 11:27 AM, Hugo Mills wrote:
>>
>>Definitely don't use parity RAID on 3.19. It's not really something
>> I'd trust, personally, even on 4.4, except for testing purposes.
>
> ++ - raid 5/6 are fairly
On Tue, Mar 1, 2016 at 11:27 AM, Hugo Mills wrote:
>
>Definitely don't use parity RAID on 3.19. It's not really something
> I'd trust, personally, even on 4.4, except for testing purposes.
++ - raid 5/6 are fairly unstable at this point. Raid 1 should be just fine.
>TBH, I wouldn't real
14 matches
Mail list logo