Hi,
Does anyone know the reason subvolumes are not called just volumes? I
mean, the top subvolume is not called a volume, so there is nothing to
be "sub" of.
Also, what is the penalty of a subvolume compared to a directory? From
a design perspective, couldn't all directories just be subvolumes?
Martin wrote on 2015/08/05 09:06 +0200:
Hi,
Does anyone know the reason subvolumes are not called just volumes? I
mean, the top subvolume is not called a volume, so there is nothing to
be "sub" of.
Because normally a volume is referred as a complete filesystem.
So from this respect, subvolume
On Wed, Aug 5, 2015 at 2:08 AM, Qu Wenruo wrote:
> The regression is introduced in v4.2-rc1, with the big btrfs qgroup
> change.
> The problem is, qgroup reserved space is never freed, causing even we
> increase the limit, we can still hit the EDQUOT much faster than it
> should.
>
> Reported-by:
If a file lost all its file extents, fsck will unable to print out the
hole.
Add an extra judgment to print out the hole range.
Signed-off-by: Qu Wenruo
---
cmds-check.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/cmds-check.c b/cmds-check.c
index 50bb6f3..31ed589
A bug reported by Robert Munteanu, which btrfsck infinite loops on an
inode with discount file extent.
This patchset includes a fix in printing file extent hole, fix the
infinite loop, and corresponding test case.
BTW, thanks Robert Munteanu a lot for its detailed debug report, makes
it super fas
For a special case, discount file extent repair function will cause
infinite loop.
The case is, if the file loses all its file extent, we won't have a hole
to fill, causing repair function doing nothing, and since the
I_ERR_DISCOUNT doesn't disappear, the fsck will do infinite loop.
For such case
Add test case with no file extents, but still non-zero inode size.
To test whether fsck will infinite loop.
Signed-off-by: Qu Wenruo
---
.../017-missing-all-file-extent/default_case.img.xz | Bin 0 -> 1104 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644
tests/fsck
I can reproduce a hard btrfs lockup (process issuing the ioctl() is in
D-state, same goes for btrfs-transacti process) on Kernel 4.2.0-rc5.
I had the same issue on 4.1, so it's unlikely a regression introduced in
4.2.
## With the following steps, I can reproduce the problem:
1. Create a new clea
Scrub output following error message in my test:
ERROR: scrubbing /var/ltf/tester/scratch_mnt failed for device id 5 (Success)
It is caused by a broken kernel and fs, but the we need to avoid
outputting both "error and success" in oneline message as above.
This patch modified above message to:
It can reduce current duplicated code which is similar to
scrub_blocked_if_needed() but can not call it because little
different.
It also used by my next patch which is in same case.
Signed-off-by: Zhao Lei
---
fs/btrfs/scrub.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
d
Use new intruduced scrub_pause_on/off() can make this code block
clean and more readable.
Signed-off-by: Zhao Lei
---
fs/btrfs/scrub.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index cbfb8c7..a882a34 100644
--- a/fs/btrfs/s
xfstests btrfs/070 sometimes failed.
In my test machine, its fail rate is about 30%.
In another vm(vmware), its fail rate is about 50%.
Reason:
btrfs/070 do replace and defrag with fsstress simultaneously,
after above operation, checksum error is found by scrub.
Actually, it have no relatio
This patchset is used to fix data checksum error cause by replace with
io-load.
It cause xfstests btrfs/070(071) failed randomly.
See description in [PATCH 4/4] for detail.
Changelog v3->v4:
1: Fix regression of xfstests/061
Patch v3 cause xfstests/061 failed in some case, because
btrfs_
More than one code call set_block_group_ro() and restore rw in fail.
Old code use bool bit to save blockgroup's ro state, it can not
support parallel case(it is confirmd exist in my debug log).
This patch use ref count to store ro state, and rename
set_block_group_ro/set_block_group_rw
to
inc_blo
From: Michal Hocko
__GFP_NOFAIL is a big hammer used to ensure that the allocation
request can never fail. This is a strong requirement and as such
it also deserves a special treatment when the system is OOM. The
primary problem here is that the allocation request might have
come with some locks
From: Michal Hocko
alloc_btrfs_bio is relying on GFP_NOFS to allocate a bio but since "mm:
page_alloc: do not lock up GFP_NOFS allocations upon OOM" this is
allowed to fail which can lead to
[ 37.928625] kernel BUG at fs/btrfs/extent_io.c:4045
This is clearly undesirable and the nofail behavio
From: Michal Hocko
Btrfs relies on GFP_NOFS allocation when commiting the transaction but
since "mm: page_alloc: do not lock up GFP_NOFS allocations upon OOM"
those allocations are allowed to fail which can lead to a pre-mature
transaction abort:
[ 55.328093] Call Trace:
[ 55.328890] [] dum
From: Michal Hocko
Journal transaction might fail prematurely because the frozen_buffer
is allocated by GFP_NOFS request:
[ 72.440013] do_get_write_access: OOM for frozen_buffer
[ 72.440014] EXT4-fs: ext4_reserve_inode_write:4729: aborting transaction:
Out of memory in __ext4_journal_get_wri
From: Michal Hocko
journal_get_undo_access is relying on GFP_NOFS allocation yet it is
essential for the journal transaction:
[ 83.256914] journal_get_undo_access: No memory for committed data
[ 83.258022] EXT3-fs: ext3_free_blocks_sb: aborting transaction: Out
of memory in __ext3_journal_ge
From: Michal Hocko
Since "mm: page_alloc: do not lock up GFP_NOFS allocations upon OOM"
memory allocator doesn't endlessly loop to satisfy low-order allocations
and instead fails them to allow callers to handle them gracefully.
Some of the callers are not yet prepared for this behavior though. e
From: Johannes Weiner
GFP_NOFS allocations are not allowed to invoke the OOM killer since
their reclaim abilities are severely diminished. However, without the
OOM killer available there is no hope of progress once the reclaimable
pages have been exhausted.
Don't risk hanging these allocations.
From: Michal Hocko
page_cache_read has been historically using page_cache_alloc_cold to
allocate a new page. This means that mapping_gfp_mask is used as the
base for the gfp_mask. Many filesystems are setting this mask to
GFP_NOFS to prevent from fs recursion issues. page_cache_read is,
however,
Hi,
small GFP_NOFS, like GFP_KERNEL, allocations have not been not failing
traditionally even though their reclaim capabilities are restricted
because the VM code cannot recurse into filesystems to clean dirty
pages. At the same time these allocation requests do not allow to
trigger the OOM killer
Remove chunk_objectid argument from btrfs_relocate_chunk() because
it is not necessary, it can also cleanup some code in caller for
prepare its value.
Signed-off-by: Zhao Lei
---
fs/btrfs/volumes.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/volumes.c
objectid's init-value is not used in any case, remove it.
Signed-off-by: Zhao Lei
---
fs/btrfs/relocation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 1659c94..4698928 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/r
We need error checking code for get_ref_objectid_v0() in
relocate_block_group(), to avoid unpredictable result, especially
for accessing uninitialized value(when function failed) after
this line.
Signed-off-by: Zhao Lei
---
fs/btrfs/relocation.c | 4
1 file changed, 4 insertions(+)
diff --
On 2015-08-04 13:36, John Ettedgui wrote:
On Tue, Aug 4, 2015 at 4:28 AM, Austin S Hemmelgarn
wrote:
On 2015-08-04 00:58, John Ettedgui wrote:
On Mon, Aug 3, 2015 at 8:01 PM, Qu Wenruo wrote:
Although the best practice is staying away from such converted fs, either
using pure, newly create
On Wed 05-08-15 11:51:20, mho...@kernel.org wrote:
> From: Michal Hocko
>
> Journal transaction might fail prematurely because the frozen_buffer
> is allocated by GFP_NOFS request:
> [ 72.440013] do_get_write_access: OOM for frozen_buffer
> [ 72.440014] EXT4-fs: ext4_reserve_inode_write:4729:
On Wed 05-08-15 11:51:21, mho...@kernel.org wrote:
> From: Michal Hocko
>
> Since "mm: page_alloc: do not lock up GFP_NOFS allocations upon OOM"
> memory allocator doesn't endlessly loop to satisfy low-order allocations
> and instead fails them to allow callers to handle them gracefully.
>
> Som
On Tue, Aug 4, 2015 at 4:23 PM, Sonic wrote:
> Seems that if there was someway to edit something in those first
> overwritten 32MB of disc 2 to say "hey, I'm really here, just a bit
> screwed up" maybe some of the recovery tools could actually work.
Just want to reiterate this thought.
The basic
On Wed, Aug 5, 2015 at 8:31 AM, Sonic wrote:
> The basic error in most cases with the tools at hand is that Disc 2 is
> missing so there's little the tools can do. Somewhere in those first
> 32MB should be something to properly identify the disc as part of the
> array.
Somehow manually create the
On Wed, Aug 05, 2015 at 11:51:24AM +0200, mho...@kernel.org wrote:
> From: Michal Hocko
>
> alloc_btrfs_bio is relying on GFP_NOFS to allocate a bio but since "mm:
> page_alloc: do not lock up GFP_NOFS allocations upon OOM" this is
> allowed to fail which can lead to
> [ 37.928625] kernel BUG a
On Wed, Aug 05, 2015 at 11:51:23AM +0200, mho...@kernel.org wrote:
> From: Michal Hocko
...
> Fix this by reintroducing the no-fail behavior of this allocation path
> with the explicit __GFP_NOFAIL.
>
> Signed-off-by: Michal Hocko
Reviewed-by: David Sterba
--
To unsubscribe from this list: se
On Wed, Aug 05, 2015 at 04:03:11PM +0800, Qu Wenruo wrote:
> A bug reported by Robert Munteanu, which btrfsck infinite loops on an
> inode with discount file extent.
>
> This patchset includes a fix in printing file extent hole, fix the
> infinite loop, and corresponding test case.
>
> BTW, thank
mho...@kernel.org wrote:
> From: Michal Hocko
>
> Journal transaction might fail prematurely because the frozen_buffer
> is allocated by GFP_NOFS request:
> [ 72.440013] do_get_write_access: OOM for frozen_buffer
> [ 72.440014] EXT4-fs: ext4_reserve_inode_write:4729: aborting transaction:
>
On Wed, Aug 05, 2015 at 04:32:26PM +0800, Zhao Lei wrote:
> Scrub output following error message in my test:
> ERROR: scrubbing /var/ltf/tester/scratch_mnt failed for device id 5
> (Success)
>
> It is caused by a broken kernel and fs,
In what way is it broken? Can we turn it into tests?
> but
On Wed, Aug 05, 2015 at 06:00:03PM +0800, Zhao Lei wrote:
> objectid's init-value is not used in any case, remove it.
>
> Signed-off-by: Zhao Lei
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel
On Wed, Aug 5, 2015 at 6:31 AM, Sonic wrote:
> On Tue, Aug 4, 2015 at 4:23 PM, Sonic wrote:
>> Seems that if there was someway to edit something in those first
>> overwritten 32MB of disc 2 to say "hey, I'm really here, just a bit
>> screwed up" maybe some of the recovery tools could actually wor
On Wed, Aug 05, 2015 at 06:00:04PM +0800, Zhao Lei wrote:
> Remove chunk_objectid argument from btrfs_relocate_chunk() because
> it is not necessary, it can also cleanup some code in caller for
> prepare its value.
>
> Signed-off-by: Zhao Lei
Reviewed-by: David Sterba
--
To unsubscribe from thi
On Wed, Aug 05, 2015 at 06:00:02PM +0800, Zhao Lei wrote:
> We need error checking code for get_ref_objectid_v0() in
> relocate_block_group(), to avoid unpredictable result, especially
> for accessing uninitialized value(when function failed) after
> this line.
>
> Signed-off-by: Zhao Lei
Review
On Wed, Aug 05, 2015 at 09:06:40AM +0200, Martin wrote:
> Also, what is the penalty of a subvolume compared to a directory? From
> a design perspective, couldn't all directories just be subvolumes?
They could, but this would bring severe performance drop.
* creating a subvolume implies a transact
On Wed, Jul 08, 2015 at 03:32:48PM +0800, Anand Jain wrote:
> This patch adds the support to show seed device on the btrfs sysfs.
> This is a revamped version of the previously single patch 6/6, and plus
> incorporates David suggestion to add seed fsid under the 'seed' kobject.
>
> Since this adds
On 2015-07-22 07:00, Russell Coker wrote:
On Tue, 23 Jun 2015 02:52:43 AM Chris Murphy wrote:
OK I actually don't know what the intended block layer behavior is
when unplugging a device, if it is supposed to vanish, or change state
somehow so that thing that depend on it can know it's "missing"
Am Mittwoch, 5. August 2015, 13:32:41 schrieb Austin S Hemmelgarn:
> On 2015-07-22 07:00, Russell Coker wrote:
> > On Tue, 23 Jun 2015 02:52:43 AM Chris Murphy wrote:
> >> OK I actually don't know what the intended block layer behavior is
> >> when unplugging a device, if it is supposed to vanish,
On Aug 5, 2015, at 3:51 AM, mho...@kernel.org wrote:
> Hi,
> small GFP_NOFS, like GFP_KERNEL, allocations have not been not failing
> traditionally even though their reclaim capabilities are restricted
> because the VM code cannot recurse into filesystems to clean dirty
> pages. At the same time th
Hi David,
Thanks. more below.
On 08/06/2015 01:29 AM, David Sterba wrote:
On Wed, Jul 08, 2015 at 03:32:48PM +0800, Anand Jain wrote:
This patch adds the support to show seed device on the btrfs sysfs.
This is a revamped version of the previously single patch 6/6, and plus
incorporates David
Hi,
I've been running btrfs on Fedora for a while now, with bedup --defrag
running in a night-time cronjob.
Last few runs seem to have gotten stuck, without possibility of even
killing the process (kill -9 doesn't work) -- all I could do is hard
power cycle.
Did something change recently? Is bedu
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Chris Murphy
> Sent: Thursday, 6 August 2015 2:54 AM
> To: Sonic
> Cc: Btrfs BTRFS ; Hugo Mills
>
> Subject: Re: BTRFS disaster (of my own making). Is this recoverable
Hi, David Sterba
Thanks for review this patch.
> -Original Message-
> From: David Sterba [mailto:dste...@suse.com]
> Sent: Thursday, August 06, 2015 12:51 AM
> To: Zhao Lei
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] btrfs-progs: Modify confuse error message in scrub
>
> On
Hi, David Sterba
> -Original Message-
> From: David Sterba [mailto:dste...@suse.com]
> Sent: Thursday, August 06, 2015 1:03 AM
> To: Zhao Lei
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH 1/3] btrfs: Error handle for get_ref_objectid_v0() in
> relocate_block_group()
>
> On Wed,
On Wed, Aug 5, 2015 at 6:45 PM, Paul Jones wrote:
> Would it be possible to store this type of critical information twice on each
> disk, at the beginning and end? I thought BTRFS already did that, but I might
> be thinking of some other filesystem. I've had my share of these types of
> oops! m
Added a missing newline to some error messages.
Signed-off-by: Tsutomu Itoh
---
btrfs-corrupt-block.c | 2 +-
cmds-check.c | 4 ++--
cmds-send.c | 4 ++--
dir-item.c| 6 +++---
mkfs.c| 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --g
switch statement is more suitable for outputing currsponding message
for errno.
Suggested-by: David Sterba
Signed-off-by: Zhao Lei
---
cmds-scrub.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/cmds-scrub.c b/cmds-scrub.c
index 7c9318e..
Scrub output following error message in my test:
ERROR: scrubbing /var/ltf/tester/scratch_mnt failed for device id 5 (Success)
It is caused by a broken kernel and fs, but the we need to avoid
outputting both "error and success" in oneline message as above.
This patch modified above message to:
Hi, Itoh
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Tsutomu Itoh
> Sent: Thursday, August 06, 2015 11:06 AM
> To: linux-btrfs@vger.kernel.org
> Subject: [PATCH] btrfs-progs: add newline to some error messages
>
Hi, Itoh-san
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Zhao Lei
> Sent: Thursday, August 06, 2015 11:51 AM
> To: 'Tsutomu Itoh'; linux-btrfs@vger.kernel.org
> Subject: RE: [PATCH] btrfs-progs: add newline to som
On 2015/08/06 12:51, Zhao Lei wrote:
Hi, Itoh
-Original Message-
From: linux-btrfs-ow...@vger.kernel.org
[mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Tsutomu Itoh
Sent: Thursday, August 06, 2015 11:06 AM
To: linux-btrfs@vger.kernel.org
Subject: [PATCH] btrfs-progs: add newlin
Hi, Itho-san
> -Original Message-
> From: Tsutomu Itoh [mailto:t-i...@jp.fujitsu.com]
> Sent: Thursday, August 06, 2015 12:01 PM
> To: Zhao Lei; linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH] btrfs-progs: add newline to some error messages
>
> On 2015/08/06 12:51, Zhao Lei wrote:
> >
58 matches
Mail list logo