On 4.12.18 г. 22:14 ч., Wilson, Ellis wrote:
> On 12/4/18 8:07 AM, Nikolay Borisov wrote:
>> On 3.12.18 г. 20:20 ч., Wilson, Ellis wrote:
>>> With 14TB drives available today, it doesn't take more than a handful of
>>> drives to result in a filesystem that takes around a minute to mount.
>>> As
We don't have any header declaring btrfs_recover_chunk_tree() nor
btrfs_recover_superblocks(), thus W=1 gives missing-prototypes warning
on them.
Fix it by introducing a new header, rescue.h for these two functions, so
make W=1 could be much happier.
Signed-off-by: Qu Wenruo
Reviewed-by:
Under most case, we are just using 'int' for 'unsigned int', and doesn't
care about the sign.
The Wsign-compare is causing tons of false alerts.
Suppressing it would make W=1 less noisy so we can focus on real
problem, while still allow it in W=3 build.
Signed-off-by: Qu Wenruo
---
Make the following functions static to avoid missing-prototypes warning:
- btrfs.c::handle_special_globals()
- check/mode-lowmem.c::repair_ternary_lowmem()
- extent-tree.c::btrfs_search_overlap_extent()
- free-space-tree.c::convert_free_space_to_bitmaps()
-
Prototypes for arg_strtou64() and lookup_path_rootid() are included in
utils.c, resulting make W=1 warning for them.
Just include that header to make W=1 happier.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
utils-lib.c | 1 +
1 file changed, 1 insertion(+)
diff --git
messages.h:49:24: warning: suggest braces around empty body in an 'if'
statement [-Wempty-body]
PRINT_TRACE_ON_ERROR;\
Just extra braces would solve the problem.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
messages.h | 15 ++-
1 file changed, 10
And fsfeatures.c is indeed a better location for that function.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
fsfeatures.c | 23 +++
utils.c | 23 ---
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/fsfeatures.c
The only hit is the following code:
tlv_len = le16_to_cpu(tlv_hdr->tlv_len);
if (tlv_type == 0 || tlv_type > BTRFS_SEND_A_MAX
|| tlv_len > BTRFS_SEND_BUF_SIZE) {
error("invalid tlv in cmd tlv_type = %hu, tlv_len =
%hu",
set_free_space_tree_thresholds() is never used, just remove it to solve
the missing-prototypes warning from make W=1.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
free-space-tree.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/free-space-tree.c
GCC 8.2.1 will report the following warning with "make W=1":
ctree.c: In function 'btrfs_next_sibling_tree_block':
ctree.c:2990:21: warning: 'slot' may be used uninitialized in this function
[-Wmaybe-uninitialized]
path->slots[level] = slot;
~~~^~
The culprit is
Although most fallthrough case is pretty obvious, we still need to teach
the dumb compiler that it's an explicit fallthrough.
Also reformat the code to use common indent.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
utils.c | 30 ++
1 file changed, 22
Add __attribute__ ((format (printf, 4, 0))) to fix the vprintf calling
function.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
---
string-table.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/string-table.c b/string-table.c
index 95833768960d..455285702d51 100644
---
This patchset can be fetched from github:
https://github.com/adam900710/btrfs-progs/tree/warning_fixes
Which is based on v4.19 tag.
This patchset will make "make W=1" reports no warning.
This patch will first introduce fix to Makefile.extrawarn to make
"cc-disable-warning" works, then disable
We imported cc-option but forgot to import cc-disable-warning.
Fixes: b556a992c3ad ("btrfs-progs: build: allow to build with various compiler
warnings")
Signed-off-by: Qu Wenruo
---
Makefile.extrawarn | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Makefile.extrawarn
From: Su Yanjun
When using gcc8 + glibc 2.28.5 compiles utils.c, it complains as below:
utils.c:852:45: warning: '%s' directive output may be truncated writing
up to 4095 bytes into a region of size 4084 [-Wformat-truncation=]
snprintf(path, sizeof(path), "/dev/mapper/%s", name);
Will do, thanks!
- mike
On Tue, Dec 4, 2018 at 9:24 PM Qu Wenruo wrote:
>
>
>
> On 2018/12/5 上午6:33, Mike Javorski wrote:
> > On Tue, Dec 4, 2018 at 2:18 AM Qu Wenruo wrote:
> >>
> >>
> >>
> >> On 2018/12/4 上午11:32, Mike Javorski wrote:
> >>> Need a bit of advice here ladies / gents. I am
On 2018/12/4 下午8:17, David Sterba wrote:
> On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote:
>> The only location is the following code:
>>
>> int level = path->lowest_level + 1;
>> BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL);
>> while(level < BTRFS_MAX_LEVEL) {
>>
On 2018/12/5 上午6:33, Mike Javorski wrote:
> On Tue, Dec 4, 2018 at 2:18 AM Qu Wenruo wrote:
>>
>>
>>
>> On 2018/12/4 上午11:32, Mike Javorski wrote:
>>> Need a bit of advice here ladies / gents. I am running into an issue
>>> which Qu Wenruo seems to have posted a patch for several weeks ago
>>>
On Tue, Dec 04, 2018 at 05:22:19PM +0200, Nikolay Borisov wrote:
> > @@ -3874,16 +3882,9 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info,
> > u64 devid, u64 start,
> > if (ret) {
> > mutex_unlock(_info->scrub_lock);
> >
On Tue, Dec 4, 2018 at 2:18 AM Qu Wenruo wrote:
>
>
>
> On 2018/12/4 上午11:32, Mike Javorski wrote:
> > Need a bit of advice here ladies / gents. I am running into an issue
> > which Qu Wenruo seems to have posted a patch for several weeks ago
> > (see
On 28 Nov 2018, at 11:05, Andrea Gelmini wrote:
> On Tue, Nov 27, 2018 at 10:16:52PM +0800, Qu Wenruo wrote:
>>
>> But it's less a concerning problem since it doesn't reach latest RC,
>> so
>> if you could reproduce it stably, I'd recommend to do a bisect.
>
> No problem to bisect, usually.
>
On 12/4/18 8:07 AM, Nikolay Borisov wrote:
> On 3.12.18 г. 20:20 ч., Wilson, Ellis wrote:
>> With 14TB drives available today, it doesn't take more than a handful of
>> drives to result in a filesystem that takes around a minute to mount.
>> As a result of this, I suspect this will become an
On Tue, Dec 4, 2018 at 3:09 AM Patrick Dijkgraaf
wrote:
>
> Hi Chris,
>
> See the output below. Any suggestions based on it?
If they're SATA drives, they may not support SCT ERC; and if they're
SAS, depending on what controller they're behind, smartctl might need
a hint to properly ask the drive
On Tue, Dec 04, 2018 at 01:46:58PM +0200, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 18:06 ч., Josef Bacik wrote:
> > The throttle path doesn't take cleaner_delayed_iput_mutex, which means
> > we could think we're done flushing iputs in the data space reservation
> > path when we could have a
On Tue, Dec 04, 2018 at 11:21:14AM +0200, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 18:06 ч., Josef Bacik wrote:
> > The cleaner thread usually takes care of delayed iputs, with the
> > exception of the btrfs_end_transaction_throttle path. The cleaner
> > thread only gets woken up every 30
Le 03/12/2018 à 23:22, Hans van Kranenburg a écrit :
> [...]
> Yes, I think that's true. See btrfs_read_block_groups in extent-tree.c:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/extent-tree.c#n9982
>
> What the code is doing here is starting at the
On 21.11.18 г. 17:10 ч., Nikolay Borisov wrote:
> Running btrfs/124 in a loop hung up on me sporadically with the
> following call trace:
> btrfs D0 5760 5324 0x
> Call Trace:
>? __schedule+0x243/0x800
>schedule+0x33/0x90
>
On 4.12.18 г. 17:11 ч., David Sterba wrote:
> The scrub context is allocated with GFP_KERNEL and called from
> btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe
> regarding reclaim that could try to flush filesystem data in order to
> get the memory. And the
On 4.12.18 г. 17:11 ч., David Sterba wrote:
> We can pass fs_info directly as this is the only member of btrfs_device
> that's bing used inside scrub_setup_ctx.
>
> Signed-off-by: David Sterba
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/scrub.c | 9 -
> 1 file changed, 4
I've instrumented the scrub alloctions to check for the GFP_NOFS context
and whether the device_list_mutex is not held. This caught one
allocation, and I've used the instrumented code to verify that Filipe's
scrub/reclaim fix is correct.
There are some debugging helpers need that live in the
The scrub context is allocated with GFP_KERNEL and called from
btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe
regarding reclaim that could try to flush filesystem data in order to
get the memory. And the device_list_mutex is held during superblock
commit, so this would
We can pass fs_info directly as this is the only member of btrfs_device
that's bing used inside scrub_setup_ctx.
Signed-off-by: David Sterba
---
fs/btrfs/scrub.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index
Le 04/12/2018 à 03:52, Chris Murphy a écrit :
> On Mon, Dec 3, 2018 at 1:04 PM Lionel Bouton
> wrote:
>> Le 03/12/2018 à 20:56, Lionel Bouton a écrit :
>>> [...]
>>> Note : recently I tried upgrading from 4.9 to 4.14 kernels, various
>>> tuning of the io queue (switching between classic
On Wed, Nov 28, 2018 at 02:40:07PM +, Filipe Manana wrote:
> > > Well, the worker tasks can also not use gfp_kernel, since the scrub
> > > task waits for them to complete before pausing.
> > > I missed this, and 2 reviewers as well, so perhaps it wasn't that
> > > trivial and I shouldn't feel
On Thu, Nov 29, 2018 at 11:33:38AM +0800, Lu Fengqi wrote:
> The @found is always false when it comes to the if branch. Besides, the
> bool type is more suitable for @found. Change the return value of the
> function and its caller to bool as well.
>
> Signed-off-by: Lu Fengqi
Added to
On Thu, Nov 29, 2018 at 05:31:32PM +0800, Lu Fengqi wrote:
> The btrfs/001 with inode_cache mount option will encounter the following
> warning:
>
> WARNING: CPU: 1 PID: 23700 at fs/btrfs/inode.c:956
> cow_file_range.isra.19+0x32b/0x430 [btrfs]
> CPU: 1 PID: 23700 Comm: btrfs Kdump: loaded
On Wed, Nov 28, 2018 at 02:54:28PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The log tree has a long standing problem that when a file is fsync'ed we
> only check for new ancestors, created in the current transaction, by
> following only the hard link for which the fsync was
On 2018/12/4 下午9:52, David Sterba wrote:
> On Tue, Dec 04, 2018 at 06:15:13PM +0800, Qu Wenruo wrote:
>> Gentle ping.
>>
>> Please put this patch into current release as the new block group size
>> limit check introduced in v4.19 is causing at least 2 reports in mail list.
>
> BTW, if there's
On 2018-12-04 08:37, Graham Cobb wrote:
On 04/12/2018 12:38, Austin S. Hemmelgarn wrote:
In short, USB is _crap_ for fixed storage, don't use it like that, even
if you are using filesystems which don't appear to complain.
That's useful advice, thanks.
Do you (or anyone else) have any
On Tue, Dec 04, 2018 at 06:15:13PM +0800, Qu Wenruo wrote:
> Gentle ping.
>
> Please put this patch into current release as the new block group size
> limit check introduced in v4.19 is causing at least 2 reports in mail list.
BTW, if there's an urgent fix or patch that should be considered for
On 04/12/2018 12:38, Austin S. Hemmelgarn wrote:
> In short, USB is _crap_ for fixed storage, don't use it like that, even
> if you are using filesystems which don't appear to complain.
That's useful advice, thanks.
Do you (or anyone else) have any experience of using btrfs over iSCSI? I
was
On Tue, Dec 04, 2018 at 06:15:13PM +0800, Qu Wenruo wrote:
> Gentle ping.
>
> Please put this patch into current release as the new block group size
> limit check introduced in v4.19 is causing at least 2 reports in mail list.
I see, on the way to 4.20-rc with stable tags. Thanks.
On 2018/12/4 下午9:07, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 20:20 ч., Wilson, Ellis wrote:
>> Hi all,
>>
>> Many months ago I promised to graph how long it took to mount a BTRFS
>> filesystem as it grows. I finally had (made) time for this, and the
>> attached is the result of my
On Fri, Nov 30, 2018 at 06:27:58PM +0200, Nikolay Borisov wrote:
>
>
> On 30.11.18 г. 17:22 ч., Chris Mason wrote:
> > On 29 Nov 2018, at 12:37, Nikolay Borisov wrote:
> >
> >> On 29.11.18 г. 18:43 ч., Jean Fobe wrote:
> >>> Hi all,
> >>> I've been studying LZ4 and other compression
On 3.12.18 г. 20:20 ч., Wilson, Ellis wrote:
> Hi all,
>
> Many months ago I promised to graph how long it took to mount a BTRFS
> filesystem as it grows. I finally had (made) time for this, and the
> attached is the result of my testing. The image is a fairly
> self-explanatory graph,
On Tue, Dec 04, 2018 at 08:34:15AM +0200, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 19:25 ч., David Sterba wrote:
> > On Sat, Nov 17, 2018 at 09:29:27AM +0800, Anand Jain wrote:
> >>> - ret = find_free_dev_extent(trans, device, min_free,
> >>> -
On Tue, Dec 04, 2018 at 08:24:38PM +0800, Qu Wenruo wrote:
>
>
> On 2018/12/4 下午8:22, David Sterba wrote:
> > On Fri, Nov 16, 2018 at 04:04:51PM +0800, Qu Wenruo wrote:
> >> The following missing prototypes will be fixed:
> >> 1) btrfs.c::handle_special_globals()
> >> 2)
On 4.12.18 г. 14:22 ч., Adam Borowski wrote:
> On Tue, Dec 04, 2018 at 01:17:04PM +0100, David Sterba wrote:
>> On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote:
>>> The only location is the following code:
>>>
>>> int level = path->lowest_level + 1;
>>>
On 2018-12-04 00:37, Tomasz Chmielewski wrote:
I'm trying to use btrfs on an external USB drive, without much success.
When the drive is connected for 2-3+ days, the filesystem gets remounted
readonly, with BTRFS saying "IO failure":
[77760.444607] BTRFS error (device sdb1): bad tree block
On 2018/12/4 下午8:22, David Sterba wrote:
> On Fri, Nov 16, 2018 at 04:04:51PM +0800, Qu Wenruo wrote:
>> The following missing prototypes will be fixed:
>> 1) btrfs.c::handle_special_globals()
>> 2) check/mode-lowmem.c::repair_ternary_lowmem()
>> 3)
On Tue, Dec 04, 2018 at 01:17:04PM +0100, David Sterba wrote:
> On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote:
> > The only location is the following code:
> >
> > int level = path->lowest_level + 1;
> > BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL);
> > while(level <
On Fri, Nov 16, 2018 at 04:04:51PM +0800, Qu Wenruo wrote:
> The following missing prototypes will be fixed:
> 1) btrfs.c::handle_special_globals()
> 2) check/mode-lowmem.c::repair_ternary_lowmem()
> 3) extent-tree.c::btrfs_search_overlap_extent()
> Above 3 can be fixed by making them
On 2018/12/4 下午7:10, David Sterba wrote:
> On Fri, Nov 16, 2018 at 03:54:19PM +0800, Qu Wenruo wrote:
>> From: Su Yanjun
>>
>> When using gcc8 compiles utils.c, it complains as below:
>>
>> utils.c:852:45: warning: '%s' directive output may be truncated writing
>> up to 4095 bytes into a region
On Fri, Nov 16, 2018 at 03:54:24PM +0800, Qu Wenruo wrote:
> The only location is the following code:
>
> int level = path->lowest_level + 1;
> BUG_ON(path->lowest_level + 1 >= BTRFS_MAX_LEVEL);
> while(level < BTRFS_MAX_LEVEL) {
> slot = path->slots[level] + 1;
>
On 3.12.18 г. 18:06 ч., Josef Bacik wrote:
> The throttle path doesn't take cleaner_delayed_iput_mutex, which means
> we could think we're done flushing iputs in the data space reservation
> path when we could have a throttler doing an iput. There's no real
> reason to serialize the delayed
On Fri, Nov 30, 2018 at 01:15:23PM +0800, Anand Jain wrote:
> @@ -3757,10 +3757,13 @@ static noinline_for_stack int
> scrub_workers_get(struct btrfs_fs_info *fs_info,
>
> static noinline_for_stack void scrub_workers_put(struct btrfs_fs_info
> *fs_info)
> {
> +
On Fri, Nov 16, 2018 at 04:00:40PM +0800, Qu Wenruo wrote:
> Under most case, we are just using 'int' for 'unsigned int', and doesn't
> care about the sign.
>
> The Wsign-compare is causing tons of false alerts.
> Suppressing it would make W=1 less noisy.
>
> Signed-off-by: Qu Wenruo
> ---
>
On Fri, Nov 16, 2018 at 03:54:19PM +0800, Qu Wenruo wrote:
> From: Su Yanjun
>
> When using gcc8 compiles utils.c, it complains as below:
>
> utils.c:852:45: warning: '%s' directive output may be truncated writing
> up to 4095 bytes into a region of size 4084 [-Wformat-truncation=]
>
On Fri, Nov 16, 2018 at 03:54:18PM +0800, Qu Wenruo wrote:
> We imported cc-option but forgot to import cc-disable-warning.
>
> Fixes: b556a992c3ad ("btrfs-progs: build: allow to build with various
> compiler warnings")
> Signed-off-by: Qu Wenruo
> ---
> Makefile.extrawarn | 6 ++
> 1 file
On Tue, Nov 27, 2018 at 04:38:23PM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/image_recover
>
> The base commit is as usual, the latest stable tag, v4.19.
>
>
> Test case misc/021 will fail if using latest upstream
On 2018/12/4 下午6:20, David Sterba wrote:
> On Tue, Nov 27, 2018 at 04:38:24PM +0800, Qu Wenruo wrote:
>> +error:
>> +error(
>> +"failed to fix chunks and devices mapping, the fs may not be mountable: %s",
>> +strerror(-ret));
>
> Recently the sterror(error code) have been
On 2018/12/4 下午6:18, David Sterba wrote:
> On Tue, Nov 27, 2018 at 04:50:57PM +0800, Qu Wenruo wrote:
-static int fixup_devices(struct btrfs_fs_info *fs_info,
- struct mdrestore_struct *mdres, off_t dev_size)
+static int fixup_device_size(struct
On Tue, Nov 27, 2018 at 04:38:24PM +0800, Qu Wenruo wrote:
> +error:
> + error(
> +"failed to fix chunks and devices mapping, the fs may not be mountable: %s",
> + strerror(-ret));
Recently the sterror(error code) have been converted to %m, so I changed
this to
errno =
On Tue, Nov 27, 2018 at 04:50:57PM +0800, Qu Wenruo wrote:
> >> -static int fixup_devices(struct btrfs_fs_info *fs_info,
> >> - struct mdrestore_struct *mdres, off_t dev_size)
> >> +static int fixup_device_size(struct btrfs_trans_handle *trans,
> >> + struct
On 2018/12/4 上午11:32, Mike Javorski wrote:
> Need a bit of advice here ladies / gents. I am running into an issue
> which Qu Wenruo seems to have posted a patch for several weeks ago
> (see https://patchwork.kernel.org/patch/10694997/).
>
> Here is the relevant dmesg output which led me to Qu's
Gentle ping.
Please put this patch into current release as the new block group size
limit check introduced in v4.19 is causing at least 2 reports in mail list.
Thanks,
Qu
On 2018/11/23 上午9:06, Qu Wenruo wrote:
> [BUG]
> A completely valid btrfs will refuse to mount, with error message like:
>
Hi Chris,
See the output below. Any suggestions based on it?
Thanks!
--
Groet / Cheers,
Patrick Dijkgraaf
On Mon, 2018-12-03 at 20:16 -0700, Chris Murphy wrote:
> Also useful information for autopsy, perhaps not for fixing, is to
> know whether the SCT ERC value for every drive is less than
Hi, thanks again.
Please see answers inline.
--
Groet / Cheers,
Patrick Dijkgraaf
On Mon, 2018-12-03 at 08:35 +0800, Qu Wenruo wrote:
>
> On 2018/12/2 下午5:03, Patrick Dijkgraaf wrote:
> > Hi Qu,
> >
> > Thanks for helping me!
> >
> > Please see the reponses in-line.
> > Any suggestions
On 3.12.18 г. 18:06 ч., Josef Bacik wrote:
> The cleaner thread usually takes care of delayed iputs, with the
> exception of the btrfs_end_transaction_throttle path. The cleaner
> thread only gets woken up every 30 seconds, so instead wake it up to do
> it's work so that we can free up that
On 3.12.18 г. 18:06 ч., Josef Bacik wrote:
> Delayed iputs means we can have final iputs of deleted inodes in the
> queue, which could potentially generate a lot of pinned space that could
> be free'd. So before we decide to commit the transaction for ENOPSC
> reasons, run the delayed iputs so
70 matches
Mail list logo
