On Mon, Jun 26, 2017 at 04:55:04PM +0200, David Sterba wrote:
>On Thu, Jun 22, 2017 at 04:12:56PM +0800, Lu Fengqi wrote:
>> As Qu mentioned in this thread
>> (https://www.spinics.net/lists/linux-btrfs/msg64469.html), compression
>> can cause regular extent to co-exist with inlined extent. This coe
Adam, I’ve applied the same patch in my tree. I’ll send out the update [1]
once it's reviewed, since I also reduced the stack usage of functions
using over 1 KB of stack space.
You’re right that div_u64() will work, since the FSE functions are only
called on blocks of at most 128 KB at a time. Per
David Sterba wrote:
> > Thus, you want do_div() instead of /; do check widths and signedness of
> > arguments.
>
> No do_div please, div_u64 or div64_u64.
Good to know, the interface of do_div() is indeed weird.
I guess Nick has found and fixed the offending divisions in his tree
already, but thi
> > - u32 free_inodes_count;
> > + u64 first_data_block;
> > + u64 block_count;
> > + u64 inodes_count;
> > + u64 free_inodes_count;
>
> I've split this change from the patch as it does not logically belong to
> the same patch, altough the change is simple.
Okay sure, thanks.
Cheers.
At 06/27/2017 09:59 AM, Anand Jain wrote:
On 06/27/2017 09:05 AM, Qu Wenruo wrote:
At 06/27/2017 02:59 AM, David Sterba wrote:
On Thu, Mar 09, 2017 at 09:34:35AM +0800, Qu Wenruo wrote:
Btrfs currently uses num_tolerated_disk_barrier_failures to do global
check for tolerated missing devi
At 06/27/2017 02:02 AM, Liu Bo wrote:
On Mon, Jun 26, 2017 at 04:09:53PM +0200, David Sterba wrote:
On Fri, Jun 23, 2017 at 10:28:31PM -0600, Liu Bo wrote:
From: Liu Bo
Ah, my From was broken again.
%search_start is calculated in a wrong way, and if %ins is a cross-stripe
one, it'll s
On 06/27/2017 09:05 AM, Qu Wenruo wrote:
At 06/27/2017 02:59 AM, David Sterba wrote:
On Thu, Mar 09, 2017 at 09:34:35AM +0800, Qu Wenruo wrote:
Btrfs currently uses num_tolerated_disk_barrier_failures to do global
check for tolerated missing device.
Although the one-size-fit-all solution i
At 06/27/2017 07:55 AM, Liu Bo wrote:
So btrfs_set_header_flags() vs btrfs_set_header_flag, the difference is sort of
similar to "=" vs "|=", when creating and initialising a new extent buffer,
convert uses the former one which clears header_rev by accident.
Thanks for catching this one.
Rev
At 06/27/2017 02:59 AM, David Sterba wrote:
On Thu, Mar 09, 2017 at 09:34:35AM +0800, Qu Wenruo wrote:
Btrfs currently uses num_tolerated_disk_barrier_failures to do global
check for tolerated missing device.
Although the one-size-fit-all solution is quite safe, it's too strict
if data and me
So btrfs_set_header_flags() vs btrfs_set_header_flag, the difference is sort of
similar to "=" vs "|=", when creating and initialising a new extent buffer,
convert uses the former one which clears header_rev by accident.
Signed-off-by: Liu Bo
---
convert/common.c | 2 +-
1 file changed, 1 insert
Today btrfs use simple logic to make decision
compress data or not:
Selected compression algorithm try compress
data and if this save some space
store that extent as compressed.
It's Reliable way to detect uncompressible data
but it's will waste/burn cpu time for
bad/un-compressible data and add l
Heuristic code compute shannon entropy in cases when
other methods can't make clear decision
For realization that calculation it's needs floating point,
but as this doesn't possible to use floating point,
lets just precalculate all our input/output values
Signed-off-by: Timofey Titovets
---
fs/b
Add a heuristic computation before compression,
for avoiding load resource heavy compression workspace,
if data are probably can't be compressed.
Signed-off-by: Timofey Titovets
---
fs/btrfs/Makefile| 2 +-
fs/btrfs/heuristic.c | 275 +++
fs/
On Thu, Mar 09, 2017 at 09:34:35AM +0800, Qu Wenruo wrote:
> Btrfs currently uses num_tolerated_disk_barrier_failures to do global
> check for tolerated missing device.
>
> Although the one-size-fit-all solution is quite safe, it's too strict
> if data and metadata has different duplication level.
If the found %ins is crossing a stripe len, ie. BTRFS_STRIPE_LEN, we'd
search again with a stripe-aligned %search_start. The current code
calculates %search_start by adding a wrong offset, in order to fix it, the
start position of the block group should be taken, otherwise, it'll end up
with looki
Apply for a loan at 3% reply to this Email for more Info
--
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
From: Filipe Manana
In some scenarios an incremental send stream can contain link commands
with an invalid target path. Such scenarios happen after moving some
directory inode A, renaming a regular file inode B into the old name of
inode A and finally creating a new hard link for inode B at direc
From: Filipe Manana
Test that an incremental send/receive operation works correctly after
moving some directory inode A, renaming a regular file inode B into the
old name of inode A and finally creating a new hard link for inode B at
directory inode A.
This issue is fixed by the following patch
On Mon, Jun 26, 2017 at 01:58:32PM -0400, jlay...@redhat.com wrote:
> On Mon, 2017-06-26 at 08:22 -0700, Darrick J. Wong wrote:
> > On Fri, Jun 16, 2017 at 03:34:26PM -0400, Jeff Layton wrote:
> > > Just check and advance the data errseq_t in struct file before
> > > before returning from fsync on
On Mon, Jun 26, 2017 at 08:09:57PM +0800, Ming Lei wrote:
> Commit 17347cec15f919901c90(Btrfs: change how we iterate bios in endio)
> mentioned that for dio the submitted bio may be fast cloned, we
> can't access the bvec table directly for a cloned bio, so use
> bio_get_first_bvec() to retrieve th
On Mon, Jun 26, 2017 at 04:09:53PM +0200, David Sterba wrote:
> On Fri, Jun 23, 2017 at 10:28:31PM -0600, Liu Bo wrote:
> > From: Liu Bo
Ah, my From was broken again.
> >
> > %search_start is calculated in a wrong way, and if %ins is a cross-stripe
> > one, it'll search the same block group fo
On Mon, 2017-06-26 at 08:22 -0700, Darrick J. Wong wrote:
> On Fri, Jun 16, 2017 at 03:34:26PM -0400, Jeff Layton wrote:
> > Just check and advance the data errseq_t in struct file before
> > before returning from fsync on normal files. Internal filemap_*
> > callers are left as-is.
> >
> > Signed
On 6/20/17 12:06 PM, Edmund Nadolski wrote:
> It's been known for a while that the use of multiple lists
> that are periodically merged was an algorithmic problem within
> btrfs. There are several workloads that don't complete in any
> reasonable amount of time (e.g. btrfs/130) and others that cau
Hi,
a pre-release has been tagged. A bugfix release.
Changes:
* image: restoring from multiple devices
* dev stats: make --check option work
* check: fix false alert with extent hole on a NO_HOLE filesystem
* check: lowmem mode, fix false alert in case of mixed inline and compressed
On 06/23/2017 11:16 AM, David Sterba wrote:
Hi,
this is the main batch for 4.13. There are some user visible changes, see
below. The core updates improve error handling (mostly related to bios), with
the usual incremental work on the GFP_NOFS (mis)use removal. All patches have
been in for-next f
Thanks for the clarification! I will fix the divisions.
On 6/26/17, 5:12 AM, "David Sterba" wrote:
On Sun, Jun 25, 2017 at 11:30:22PM +0200, Adam Borowski wrote:
> On Mon, Jun 26, 2017 at 03:03:17AM +0800, kbuild test robot wrote:
> > Hi Nick,
> >
> > url:
https://github
On Thu, Jun 22, 2017 at 03:31:07PM +0200, Jan Kara wrote:
> When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
> set, DIR1 is expected to have SGID bit set (and owning group equal to
> the owning group of 'DIR0'). However when 'DIR0' also has some default
> ACLs that 'DIR1' in
Hi,
a friendly reminder of the timetable and what's expected at this phase.
4.11 - current
4.12 - upcoming, urgent regression fixes only
4.13 - development closed, pull request pending, fixes or regressions only
4.14 - development open, until 4.13-rc5
(https://btrfs.wiki.kernel.org/index.php/Dev
On 26.06.2017 17:42, Nikolay Borisov wrote:
> With this patch applied pahole stats look like:
>
> /* size: 840, cachelines: 14, members: 40 */
> /* sum members: 833, holes: 1, sum holes: 7 */
> /* bit holes: 1, sum bit holes: 28 bits */
> /* last cacheline: 8 bytes */
>
> No functional changes.
On Fri, Jun 16, 2017 at 03:34:26PM -0400, Jeff Layton wrote:
> Just check and advance the data errseq_t in struct file before
> before returning from fsync on normal files. Internal filemap_*
> callers are left as-is.
>
> Signed-off-by: Jeff Layton
> ---
> fs/xfs/xfs_file.c | 15 +++
On Thu, Jun 22, 2017 at 04:12:56PM +0800, Lu Fengqi wrote:
> As Qu mentioned in this thread
> (https://www.spinics.net/lists/linux-btrfs/msg64469.html), compression
> can cause regular extent to co-exist with inlined extent. This coexistence
> makes things confusing. Since it was permitted currentl
With this patch applied pahole stats look like:
/* size: 840, cachelines: 14, members: 40 */
/* sum members: 833, holes: 1, sum holes: 7 */
/* bit holes: 1, sum bit holes: 28 bits */
/* last cacheline: 8 bytes */
No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 14 +
The sectorsize member of btrfs_block_group_cache is unused. So remove it, this
reduces the number of holes in the struct.
With patch:
/* size: 856, cachelines: 14, members: 40 */
/* sum members: 837, holes: 4, sum holes: 19 */
/* bit holes: 1, sum bit holes: 29 bits */
/* last cacheline: 24 bytes
On Mon, Jun 19, 2017 at 01:26:20PM +0200, Henk Slager wrote:
> On 16-06-17 03:43, Qu Wenruo wrote:
> > Since incompat feature NO_HOLES still allow us to have explicit hole
> > file extent, current check is too restrict and will cause false alert
> > like:
> >
> > root 5 EXTENT_DATA[257, 0] shouldn'
On Sat, 2017-06-24 at 09:16 -0400, Jeff Layton wrote:
> On Sat, 2017-06-24 at 04:59 -0700, Christoph Hellwig wrote:
> > On Tue, Jun 20, 2017 at 01:44:44PM -0400, Jeff Layton wrote:
> > > In order to query for errors with errseq_t, you need a previously-
> > > sampled point from which to check. When
On Mon, Jun 26, 2017 at 06:18:29PM +0800, Gu Jinxiang wrote:
> For code maintainability and scalability,
> replace number with a macro of member blocks in btrfs_mkfs_config.
>
> Signed-off-by: Gu Jinxiang
> ---
> Changes since v1:
> Missing a using place. And modify it.
>
> mkfs/common.c | 4 ++
On Fri, Jun 23, 2017 at 10:28:31PM -0600, Liu Bo wrote:
> From: Liu Bo
>
> %search_start is calculated in a wrong way, and if %ins is a cross-stripe
> one, it'll search the same block group forever.
That's a bit terse description, so please check if my understanding is right:
search_start advan
On Fri, Jun 16, 2017 at 03:34:26PM -0400, Jeff Layton wrote:
> Just check and advance the data errseq_t in struct file before
> before returning from fsync on normal files. Internal filemap_*
> callers are left as-is.
>
Looks good.
Reviewed-by: Carlos Maiolino
> Signed-off-by: Jeff Layton
> -
On Fri, Jun 23, 2017 at 05:16:46PM +0200, David Sterba wrote:
Two more patches added to the branch
Chris Mason (1):
btrfs: fix integer overflow in calc_reclaim_items_nr
David Sterba (1):
btrfs: scrub: fix target device intialization while setting up scrub
context
Updated branch and
The commit "btrfs: scrub: inline helper scrub_setup_wr_ctx" inlined a
helper but wrongly sets up the target device. Incidentally there's a
local variable with the same name as a parameter in the previous
function, so this got caught during runtime as crash in test btrfs/027.
Reported-by: Chris Mas
On Sat, Jun 03, 2017 at 03:27:45PM +0530, Lakshmipathi.G wrote:
> With larger file system (in this case its 22TB), ext2fs_open() returns
> EXT2_ET_CANT_USE_LEGACY_BITMAPS error message with ext2fs_read_block_bitmap().
>
> To overcome this issue, (a) we need pass EXT2_FLAG_64BITS flag with
> ext2f
On Thu, Jun 22, 2017 at 01:27:53PM +0530, Lakshmipathi.G wrote:
> Bug 194961 - btrfs device stats --check does not work
> https://bugzilla.kernel.org/show_bug.cgi?id=194961
>
> Reported-by: Tomas Thiemel
> Signed-off-by: Lakshmipathi.G
Applied, thanks.
--
To unsubscribe from this list: send the
On Sun, Jun 25, 2017 at 11:30:22PM +0200, Adam Borowski wrote:
> On Mon, Jun 26, 2017 at 03:03:17AM +0800, kbuild test robot wrote:
> > Hi Nick,
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Nick-Terrell/lib-Add-xxhash-module/20170625-214344
> > config: i386-allmodconfig (attached
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Ming Lei
---
fs/btrfs/compression.c | 4
fs/btrfs/inode.c | 12
2 files changed, 16 insertions(+)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 2c0b7b5
Commit 17347cec15f919901c90(Btrfs: change how we iterate bios in endio)
mentioned that for dio the submitted bio may be fast cloned, we
can't access the bvec table directly for a cloned bio, so use
bio_get_first_bvec() to retrieve the 1st bvec.
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
C
BTRFS uses bio->bi_vcnt to figure out page numbers, this
way becomes not correct once we start to enable multipage
bvec.
So use bio_for_each_segment_all() to do that instead.
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Ming Lei
---
fs/btrfs
Preparing for supporting multipage bvec.
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Ming Lei
---
fs/btrfs/compression.c | 5 -
fs/btrfs/extent_io.c | 8 ++--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Ming Lei
---
fs/btrfs/compression.c | 3 ++-
fs/btrfs/disk-io.c | 3 ++-
fs/btrfs/extent_io.c | 12
fs/btrfs/inode.c | 6 --
fs/btrfs/raid56.c | 6 --
5 fil
On 2017年06月24日 10:34, Marc MERLIN wrote:
On Fri, Jun 23, 2017 at 09:17:50AM -0700, Marc MERLIN wrote:
Thanks for looking at this.
I have applied your patch and I'm still re-running check in lowmem. It takes
about 24H so I'll
post the full results when it's done.
Ok, here is the output of the
Add a image which can reproduce the extent item referencer count
mismatch false alert for lowmem mode.
Reported-by: Marc MERLIN
Signed-off-by: Lu Fengqi
---
.../ref_count_mismatch_false_alert.img | Bin 0 -> 4096 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mo
Add a image that the inlined extent coexist with the regular extent.
Reported-by: Marc MERLIN
Signed-off-by: Lu Fengqi
---
.../020-extent-ref-cases/inline_regular_coexist.img | Bin 0 -> 4096 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644
tests/fsck-tests/020-ex
As Qu mentioned in this thread
(https://www.spinics.net/lists/linux-btrfs/msg64469.html), compression
can cause regular extent to co-exist with inlined extent. This coexistence
makes things confusing. Since it was permitted currently, so fix
btrfsck to prevent a bunch of error logs that will make u
The normal back reference counting doesn't care about the extent referred
by the extent data in the shared leaf. The check_extent_data_backref
function need to skip the leaf that owner mismatch with the root_id.
Reported-by: Marc MERLIN
Signed-off-by: Lu Fengqi
---
cmds-check.c | 3 ++-
1 file
For code maintainability and scalability,
replace number with a macro of member blocks in btrfs_mkfs_config.
Signed-off-by: Gu Jinxiang
---
Changes since v1:
Missing a using place. And modify it.
mkfs/common.c | 4 ++--
mkfs/common.h | 5 -
2 files changed, 6 insertions(+), 3 deletions(-)
On 2017/06/26 17:23, Gu Jinxiang wrote:
> For code maintainability and scalability,
> replace number with a macro of member blocks in btrfs_mkfs_config.
>
> Signed-off-by: Gu Jinxiang
> ---
> mkfs/common.c | 2 +-
> mkfs/common.h | 5 -
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
>
For code maintainability and scalability,
replace number with a macro of member blocks in btrfs_mkfs_config.
Signed-off-by: Gu Jinxiang
---
mkfs/common.c | 2 +-
mkfs/common.h | 5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/mkfs/common.c b/mkfs/common.c
index e4785c5..4
On Fri, Jun 16, 2017 at 03:34:10PM -0400, Jeff Layton wrote:
> Resetting this flag is almost certainly racy, and will be problematic
> with some coming changes.
>
> Make filemap_fdatawait_keep_errors return int, but not clear the flag(s).
> Have jbd2 call it instead of filemap_fdatawait and don't
On Fri, Jun 16, 2017 at 03:34:09PM -0400, Jeff Layton wrote:
> I noticed on xfs that I could still sometimes get back an error on fsync
> on a fd that was opened after the error condition had been cleared.
>
> The problem is that the buffer code sets the write_io_error flag and
> then later checks
On Fri, Jun 16, 2017 at 03:34:06PM -0400, Jeff Layton wrote:
> Requested-by: Christoph Hellwig
> Signed-off-by: Jeff Layton
> ---
> fs/sync.c | 2 +-
> include/linux/fs.h | 6 --
> ipc/shm.c | 2 +-
> 3 files changed, 2 insertions(+), 8 deletions(-)
>
> 2.13.0
If it's wort
59 matches
Mail list logo