From: Omar Sandoval
This was originally a prep patch for changing the behavior on len=0, but
we went another direction with that. This still makes the function
slightly easier to follow.
Reviewed-by: Qu Wenruo
Signed-off-by: Omar Sandoval
---
Qu thought this would still be a worthwhile cleanup
From: Omar Sandoval
In a lot of places, it's unclear when it's safe to reuse a struct
btrfs_key after it has been passed to a helper function. Constify these
arguments wherever possible to make it obvious.
Signed-off-by: Omar Sandoval
---
This applies to Dave's for-next branch. If it's too intr
Christoph Groth wrote:
Chris Murphy wrote:
On Tue, Jan 17, 2017 at 1:25 PM, Christoph Groth
wrote:
Any ideas on what could be done? If you need help to debug
the problem with
btrfs-image, please tell me what I should do. I can keep the
broken file
system around until an image can be created
On Wed, Jan 18, 2017 at 07:17:02AM +0530, Lakshmipathi.G wrote:
> Signed-off-by: Lakshmipathi.G
Need detailed test description in commit log too.
> ---
> tests/btrfs/047 | 108
>
> tests/btrfs/047.out | 1 +
> tests/btrfs/group | 1
For btrfs-progs test case 021-partially-dropped-snapshot-case, if the
first leaf is already dropped, btrfs check low-memory mode will report
false alert:
checking fs roots
checksum verify failed on 29917184 found E4E3BDB6 wanted
checksum verify failed on 29917184 found E4E3BDB6 wanted 000
Due to commit 00e769d04c2c83029d6c71(btrfs-progs: Correct value printed
by assertions/BUG_ON/WARN_ON), which changed the assert_trace()
parameter, the condition passed to assert/WARN_ON/BUG_ON are logical
notted for backtrace enabled and disabled case.
Such behavior makes us easier to pass value w
Due to commit 00e769d04c2c83029d6c71(btrfs-progs: Correct value printed
by assertions/BUG_ON/WARN_ON), which changed the assert_trace()
parameter, the condition passed to assert/WARN_ON/BUG_ON are logical
notted for backtrace enabled and disabled case.
Such behavior makes us easier to pass value w
Due to commit 00e769d04c2c83029d6c71(btrfs-progs: Correct value printed
by assertions/BUG_ON/WARN_ON), which changed the assert_trace()
parameter, the condition passed to assert/WARN_ON/BUG_ON are logical
notted for backtrace enabled and disabled case.
Such behavior makes us easier to pass value w
Signed-off-by: Lakshmipathi.G
---
tests/btrfs/047 | 108
tests/btrfs/047.out | 1 +
tests/btrfs/group | 1 +
3 files changed, 110 insertions(+)
create mode 100755 tests/btrfs/047
create mode 100644 tests/btrfs/047.out
diff --git a/
From: Jeff Mahoney
If we call "btrfs quota rescan -w", it will attempt to start the rescan
operation, wait for it, and then print the "quota rescan started" message.
The wait could last an arbitrary amount of time, so printing it after
the wait isn't very helpful.
This patch reworks how we print
From: Jeff Mahoney
This patch adds a new -W option to wait for a rescan without starting a
new operation. This is useful for things like xfstests where we want
do to do a "btrfs quota enable" and not continue until the subsequent
rescan has finished.
In addition to documenting the new option in
On Wed, 2017-01-18 at 08:41 +0800, Qu Wenruo wrote:
> Since we have your extent tree and root tree dump, I think we should
> beĀ
> able to build a image to reproduce the case.
+1
> BTW, your fs is too large for us to really do some verification or
> otherĀ
> work.
Sure I know... but that's simply
At 01/18/2017 06:47 AM, Josef Bacik wrote:
On Mon, Jan 16, 2017 at 5:10 PM, Qu Wenruo wrote:
When dev-replace and scrub are run at the same time, dev-replace can be
canceled by scrub. It's quite common for btrfs/069.
While in that case, target device can be destroyed at cancel time,
leading
At 01/17/2017 06:39 PM, Christoph Anton Mitterer wrote:
Am 17. Januar 2017 09:53:19 MEZ schrieb Qu Wenruo :
Just lowmem false alert, as extent-tree dump shows complete fine
result.
I'll CC you and adds your reported-by tag when there is any update on
this case.
Fine, just one thing left rig
Goldwyn Rodrigues wrote:
As Chris mentioned, try a later version. If you are familiar
with git, you could even try the devel version.
Looking at the commits in current devel (2f4a73f9a612876116) since
v4.9, there doesn't seem to be anything relevant, but I can retry,
if you think it's worth.
Chris Murphy wrote:
On Tue, Jan 17, 2017 at 1:25 PM, Christoph Groth
wrote:
Any ideas on what could be done? If you need help to debug the
problem with
btrfs-image, please tell me what I should do. I can keep the
broken file
system around until an image can be created at some later time.
On 01/17/2017 02:25 PM, Christoph Groth wrote:
> Goldwyn Rodrigues wrote:
>> On 01/17/2017 02:44 AM, Christoph Groth wrote:
>>> Goldwyn Rodrigues wrote:
>>>
Would you be able to upload a btrfs-image for me to examine. This is a
core ctree error where most probably item size is incorrect
On Mon, Jan 16, 2017 at 5:10 PM, Qu Wenruo
wrote:
When dev-replace and scrub are run at the same time, dev-replace can
be
canceled by scrub. It's quite common for btrfs/069.
While in that case, target device can be destroyed at cancel time,
leading to a user-after-free bug:
Process A (de
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c| 2 +-
fs/btrfs/tree-log.c | 10 +-
fs/btrfs/tree-log.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 41b1e2ed63b4..ebfeabafe1b1 100644
--- a/fs/btrfs/inode.c
+++ b
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 38cda7869bf9..b0cc56fe86e9 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -5155,7 +5155,7 @@ struct btr
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 92 ++---
1 file changed, 45 insertions(+), 47 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 1348ab5e3229..8c110d0e16c3 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/b
Signed-off-by: Nikolay Borisov
---
fs/btrfs/btrfs_inode.h | 16 +++-
fs/btrfs/file.c| 2 +-
fs/btrfs/inode.c | 16
fs/btrfs/tree-log.c| 4 ++--
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 35434d686653..d919cd4252ba 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -991,7 +
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c| 8
fs/btrfs/tree-log.c | 18 --
fs/btrfs/tree-log.h | 2 +-
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 9442c80fe551..41b1e2ed63b4 100644
--- a/fs/btr
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 12872bf492bd..1301c517c2f0 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4277,13 +4277,13 @@ stati
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 47e4f3610348..a16da4a3ab63 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1402,7 +1402,7 @@ static int c
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index d919cd4252ba..1348ab5e3229 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3592,19 +3592,18 @@ static
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c| 2 +-
fs/btrfs/tree-log.c | 10 +-
fs/btrfs/tree-log.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ebfeabafe1b1..e86b08eabb82 100644
--- a/fs/btrfs/inode.c
+++ b
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 8d7197a0eceb..38cda7869bf9 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3450,7 +3450,7 @@ static no
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index b2c0a30811f6..35434d686653 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -843,7 +843,7 @@ static no
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index b814cd7bbe70..a2a822a993af 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -5021,13 +5021,13
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 20718cfebf89..7669e95be423 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4495,7 +4495,7 @@ static in
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c| 8
fs/btrfs/tree-log.c | 18 +-
fs/btrfs/tree-log.h | 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index d49c3b78e2fb..a8374f1d8c61 100644
--- a/fs/btr
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 40 +++-
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 7669e95be423..12872bf492bd 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index e293ae0e18d7..8d7197a0eceb 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3260,7 +3260,7 @@ static noinl
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 0e061f91055e..e293ae0e18d7 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4053,7 +405
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ordered-data.c | 4 ++--
fs/btrfs/ordered-data.h | 2 +-
fs/btrfs/tree-log.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index 041c3326d109..7ae350a64c77 100644
--- a/fs/bt
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index a7705173150e..20718cfebf89 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4241,13 +4241,13 @@ static int
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 8c110d0e16c3..47e4f3610348 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1358,14 +1358,14 @@ static int
Signed-off-by: Nikolay Borisov
---
fs/btrfs/tree-log.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 1301c517c2f0..9f2c42016825 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4372,7 +4372,7 @@ static int
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h| 2 +-
fs/btrfs/inode.c| 58 ++---
fs/btrfs/tree-log.c | 14 ++---
3 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 6a8237
So here is a new set of patches cleaning up tree-log function
w.r.t inode vs btrfs_inode. There are still some which remain
but I didn't find compelling arguments to cleaning them up, so
I've left them unchanged. This time there are some size shrinkage:
textdata bss dec hex
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ioctl.c| 2 +-
fs/btrfs/tree-log.c | 8
fs/btrfs/tree-log.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index e8e1f5f5f93a..7d1b5378de49 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/b
On Tue, Jan 17, 2017 at 1:25 PM, Christoph Groth
wrote:
> Goldwyn Rodrigues wrote:
>>
>> On 01/17/2017 02:44 AM, Christoph Groth wrote:
>>>
>>> Goldwyn Rodrigues wrote:
>>>
Would you be able to upload a btrfs-image for me to examine. This is a
core ctree error where most probably item si
On Jan 17, 2017, at 8:59 AM, Theodore Ts'o wrote:
>
> On Tue, Jan 17, 2017 at 04:18:17PM +0100, Michal Hocko wrote:
>>
>> OK, so I've been staring into the code and AFAIU current->journal_info
>> can contain my stored information. I could either hijack part of the
>> word as the ref counting is
Goldwyn Rodrigues wrote:
On 01/17/2017 02:44 AM, Christoph Groth wrote:
Goldwyn Rodrigues wrote:
Would you be able to upload a btrfs-image for me to
examine. This is a
core ctree error where most probably item size is incorrectly
registered.
Sure, I can do that. I'd like to use the -s opti
On Tue 17-01-17 17:16:19, Michal Hocko wrote:
> > > But before going to play with that I am really wondering whether we need
> > > all this with no journal at all. AFAIU what Jack told me it is the
> > > journal lock(s) which is the biggest problem from the reclaim recursion
> > > point of view. Wh
On Thu, Jan 12, 2017 at 04:00:26PM +0200, Nikolay Borisov wrote:
> So here is a new set of patches cleaning up tree-log function
> w.r.t inode vs btrfs_inode. There are still some which remain
> but I didn't find compelling arguments to cleaning them up, so
> I've left them unchanged. This time
On Tue 17-01-17 10:59:16, Theodore Ts'o wrote:
> On Tue, Jan 17, 2017 at 04:18:17PM +0100, Michal Hocko wrote:
> >
> > OK, so I've been staring into the code and AFAIU current->journal_info
> > can contain my stored information. I could either hijack part of the
> > word as the ref counting is onl
On 01/13/2017 08:24 PM, Omar Sandoval wrote:
> Hi,
>
> I'd like to attend LSF/MM again this year to discuss topics in blk-mq,
> Btrfs, and the VFS.
>
> I've been working on the blk-mq I/O scheduling framework [1] with Jens.
> Once that is finalized, the next step is a proper multiqueue scheduler.
On Tue, Jan 17, 2017 at 04:18:17PM +0100, Michal Hocko wrote:
>
> OK, so I've been staring into the code and AFAIU current->journal_info
> can contain my stored information. I could either hijack part of the
> word as the ref counting is only consuming low 12b. But that looks too
> ugly to live. O
On Thu, Jan 05, 2017 at 06:03:58PM +0100, Lakshmipathi.G wrote:
> Signed-off-by: Lakshmipathi.G
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
On Mon, Jan 09, 2017 at 01:38:08PM +0800, Su Yue wrote:
> Add a function 'repair_inode_isize' to support inode isize repair.
Similar comments to this patch, missng path init and the error message
level.
> Signed-off-by: Su Yue
> ---
> cmds-check.c | 49 ++
On Wed 11-01-17 15:13:19, Miklos Szeredi wrote:
> On Wed, Jan 11, 2017 at 12:51 PM, Jan Kara wrote:
> > On Wed 11-01-17 11:29:28, Miklos Szeredi wrote:
> >> I know there's work on this for xfs, but could this be done in generic mm
> >> code?
> >>
> >> What are the obstacles? page->mapping and pag
Hi,
I have some comments, see below.
On Mon, Jan 09, 2017 at 01:38:07PM +0800, Su Yue wrote:
> Added 'repair_inode_item' which dispatches functions such as
> 'repair_inode__nbytes_lowmem' to correct errors and
> 'struct inode_item_fix_info' to store correct values and errors.
>
> Signed-off-by:
On Tue 17-01-17 09:24:25, Michal Hocko wrote:
> On Mon 16-01-17 21:56:07, Theodore Ts'o wrote:
> > On Fri, Jan 06, 2017 at 03:11:07PM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > This reverts commit 216553c4b7f3e3e2beb4981cddca9b2027523928. Now that
> > > the transaction contex
On Mon, Jan 16, 2017 at 09:35:52AM -0700, lakshmipath...@giis.co.in wrote:
> If btrfs-corrupt-block is in bad shape, then corruption scripts around
> them won't help in long term.
>
> Yes, documentation for btrfs-corrupt-block needs improvement. imo,
> re-arranged priority will be like : (5), (
It's not clear from the test what's the purpose. There's one corrupted
csum but the whole csum tree rebuild option is used. This is a pretty
basic check that the --init-csum-tree works, so it should be mentioned
somewhere in the test script.
On Thu, Jan 05, 2017 at 08:26:36PM +0100, Lakshmipathi.G
On Thu, Jan 05, 2017 at 11:08:32AM +0100, Lakshmipathi.G wrote:
> Patch with fix for David Sterba review comment.
>
> Signed-off-by: Lakshmipathi.G
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mor
On 2017-01-17 04:18, Christoph Groth wrote:
Austin S. Hemmelgarn wrote:
There's not really much in the way of great documentation that I know
of. I can however cover the basics here:
(...)
Thanks for this explanation. I'm sure it will be also useful to others.
Glad I could help.
If the
On 2017-01-16 23:50, Janos Toth F. wrote:
BTRFS uses a 2 level allocation system. At the higher level, you have
chunks. These are just big blocks of space on the disk that get used for
only one type of lower level allocation (Data, Metadata, or System). Data
chunks are normally 1GB, Metadata 2
On 01/17/2017 02:44 AM, Christoph Groth wrote:
> Goldwyn Rodrigues wrote:
>
>> Would you be able to upload a btrfs-image for me to examine. This is a
>> core ctree error where most probably item size is incorrectly registered.
>
> Sure, I can do that. I'd like to use the -s option, will this b
Am 17. Januar 2017 09:53:19 MEZ schrieb Qu Wenruo :
>Just lowmem false alert, as extent-tree dump shows complete fine
>result.
>
>I'll CC you and adds your reported-by tag when there is any update on
>this case.
Fine, just one thing left right more from my side on this issue:
Do you want me to le
Austin S. Hemmelgarn wrote:
There's not really much in the way of great documentation that I
know of. I can however cover the basics here:
(...)
Thanks for this explanation. I'm sure it will be also useful to
others.
If the chunk to be allocated was a data chunk, you get -ENOSPC
(usual
At 01/17/2017 06:07 AM, Christoph Anton Mitterer wrote:
On Mon, 2017-01-16 at 13:47 +0800, Qu Wenruo wrote:
And I highly suspect if the subvolume 6403 is the RO snapshot you
just removed.
I guess there is no way to find out whether it was that snapshot,
is
there?
"btrfs subvolume list" cou
Goldwyn Rodrigues wrote:
Would you be able to upload a btrfs-image for me to
examine. This is a core ctree error where most probably item
size is incorrectly registered.
Sure, I can do that. I'd like to use the -s option, will this be
fine? Is there some preferred place for the upload? If
On Mon 16-01-17 21:56:07, Theodore Ts'o wrote:
> On Fri, Jan 06, 2017 at 03:11:07PM +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > This reverts commit 216553c4b7f3e3e2beb4981cddca9b2027523928. Now that
> > the transaction context uses memalloc_nofs_save and all allocations
> > within t
67 matches
Mail list logo