On Fri, May 18, 2018 at 07:37:07AM -0700, Darrick J. Wong wrote:
> On Wed, May 16, 2018 at 01:38:49PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Swap files cannot have holes, and they must at least two pages.
> > swapon(8) and mkswap(8) have stricter restrictions, so add versions
On Wed, May 16, 2018 at 01:38:47PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Similar to generic/356 that makes sure we can't reflink an active
^^^ dedupe
I'll fix it on commit.
Thanks,
Eryu
--
To unsubscribe from this list: send t
On Wed, May 16, 2018 at 01:38:46PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Commit 8c96cfbfe530 ("generic/35[67]: disable swapfile tests on Btrfs")
> disabled the swapfile tests on Btrfs because it did not support
> swapfiles at the time. Now that we're adding support, we want these
On Mon, May 21, 2018 at 07:38:55PM -0400, Kent Overstreet wrote:
> On Mon, May 21, 2018 at 02:24:32PM -0400, Mike Snitzer wrote:
> > Every single data structure change in this series should be reviewed for
> > unforeseen alignment consequences. Jens seemed to say that is
> > worthwhile. Not sure
On 2017/11/18 2:44, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Preparatory patch. It reduces the arguments to __btrfs_buffered_write
> to follow buffered_write() style.
>
> Signed-off-by: Goldwyn Rodrigues
>
> ---
> fs/btrfs/file.c | 24
> 1 file changed,
set_extent_bits may return 0/-EEXIST, so return the result in
add_excluded_extent. And handle the failures in upper callers.
Caller of add_excluded_extent and failure process currently:
exclude_super_stripes
<- btrfs_make_block_group //handles the failure
<- btrfs_read_block_group
On Mon, May 21, 2018 at 08:04:16PM -0700, Matthew Wilcox wrote:
> On Mon, May 21, 2018 at 10:19:51PM -0400, Kent Overstreet wrote:
> > New lock for bcachefs, like read/write locks but with a third state,
> > intent.
> >
> > Intent locks conflict with each other, but not with read locks; taking a
>
On Mon, May 21, 2018 at 10:19:51PM -0400, Kent Overstreet wrote:
> New lock for bcachefs, like read/write locks but with a third state,
> intent.
>
> Intent locks conflict with each other, but not with read locks; taking a
> write lock requires first holding an intent lock.
Can you put something
New lock for bcachefs, like read/write locks but with a third state,
intent.
Intent locks conflict with each other, but not with read locks; taking a
write lock requires first holding an intent lock.
The purpose is for multi node data structures (i.e. btrees), where if we were
using read/write lo
On Mon, May 21, 2018 at 05:07:19PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> I got a report that after upgrading to 4.16, someone's filesystems
> weren't mounting:
>
> [ 23.845852] BTRFS info (device loop0): unrecognized mount option 'subvol='
>
> Before 4.16, this mounted the def
From: Omar Sandoval
I got a report that after upgrading to 4.16, someone's filesystems
weren't mounting:
[ 23.845852] BTRFS info (device loop0): unrecognized mount option 'subvol='
Before 4.16, this mounted the default subvolume. It turns out that this
empty "subvol=" is actually an applicati
On Mon, May 21, 2018 at 02:24:32PM -0400, Mike Snitzer wrote:
> Every single data structure change in this series should be reviewed for
> unforeseen alignment consequences. Jens seemed to say that is
> worthwhile. Not sure if he'll do it or we divide it up. If we divide
> it up a temp topic bra
On 2018-05-21 13:43, David Sterba wrote:
On Fri, May 18, 2018 at 01:10:02PM -0400, Austin S. Hemmelgarn wrote:
On 2018-05-18 12:36, Niccolò Belli wrote:
On venerdì 18 maggio 2018 18:20:51 CEST, David Sterba wrote:
Josef started working on that in 2014 and did not finish it. The patches
can be
On Sun, May 20, 2018 at 06:25:57PM -0400, Kent Overstreet wrote:
> Signed-off-by: Kent Overstreet
Looks ok, I guess...
Acked-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_aops.c | 2 +-
> fs/xfs/xfs_aops.h | 2 +-
> fs/xfs/xfs_super.c | 11 +--
> 3 files changed, 7 insertions(+), 8 d
On Mon, May 21 2018 at 1:37pm -0400,
Kent Overstreet wrote:
>
> Uh, you came across as upset and paranoid to me too. Chalk it up to email? :)
Awesome. See how easy it is to make someone with purely constructive
questions and feedback come off as upset and paranoid?
The tipping point occurs w
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE fl
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE fl
Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM).
In function alloc_extent_state, it is obvious that __GFP_DMA is not
the expecting zone type.
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
e
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM).
In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32
is not the expecting zone type.
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for st
On Fri, May 18, 2018 at 01:10:02PM -0400, Austin S. Hemmelgarn wrote:
> On 2018-05-18 12:36, Niccolò Belli wrote:
> > On venerdì 18 maggio 2018 18:20:51 CEST, David Sterba wrote:
> >> Josef started working on that in 2014 and did not finish it. The patches
> >> can be still found in his tree. The p
On Mon, May 21, 2018 at 12:09:14PM -0400, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:36am -0400,
> Jens Axboe wrote:
>
> > On 5/21/18 9:18 AM, Mike Snitzer wrote:
> > > On Mon, May 21 2018 at 11:09am -0400,
> > > Jens Axboe wrote:
> > >
> > >> On 5/21/18 9:04 AM, Mike Snitzer wrote:
> > >>
On 5/21/18 10:09 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:36am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 9:18 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 11:09am -0400,
>>> Jens Axboe wrote:
>>>
On 5/21/18 9:04 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:52am
On Mon, May 21 2018 at 11:36am -0400,
Jens Axboe wrote:
> On 5/21/18 9:18 AM, Mike Snitzer wrote:
> > On Mon, May 21 2018 at 11:09am -0400,
> > Jens Axboe wrote:
> >
> >> On 5/21/18 9:04 AM, Mike Snitzer wrote:
> >>> On Mon, May 21 2018 at 10:52am -0400,
> >>> Jens Axboe wrote:
> >>>
...
> >>>
From: David Sterba
Hi,
a friendly reminder of the timetable and what's expected at this phase.
4.16 - current
4.17 - upcoming, urgent regression fixes only
4.18 - development closed, pull request in prep, fixes or regressions only
4.19 - development open, until 4.18-rc5 (at least)
(https://btr
On 2018-05-21 09:42, Timofey Titovets wrote:
пн, 21 мая 2018 г. в 16:16, Austin S. Hemmelgarn :
On 2018-05-19 04:54, Niccolò Belli wrote:
On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote:
With a bit of work, it's possible to handle things sanely. You can
deduplicate data f
On 5/21/18 9:18 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 11:09am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 9:04 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:52am -0400,
>>> Jens Axboe wrote:
>>>
On 5/21/18 8:47 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:36am -
On Mon, May 21, 2018 at 11:20:26PM +0800, Huaisheng Ye wrote:
> From: Huaisheng Ye
>
> Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
>
> ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
> bitmasks, the bottom three bits of GFP mask is reserved fo
From: Huaisheng Ye
Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
the bottom three bits of GFP mask is reserved for storing encoded
zone number.
The encoding method is XOR. Get zone number from enum zone_ty
From: Huaisheng Ye
Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
the bottom three bits of GFP mask is reserved for storing encoded
zone number.
The encoding method is XOR. Get zone number from enum zone_ty
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 sh
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 sh
From: Huaisheng Ye
GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.
Signed-off-by: Huaisheng Ye
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Philippe Ombredanne
---
include/linux/highmem.h
From: Huaisheng Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE
From: Huaisheng Ye
GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.
Signed-off-by: Huaisheng Ye
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: x...@kernel
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 sh
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 sh
On 5/21/18 9:12 AM, David Sterba wrote:
> On Mon, May 21, 2018 at 08:19:58AM -0600, Jens Axboe wrote:
>> On 5/21/18 8:03 AM, Mike Snitzer wrote:
>>> On Sun, May 20 2018 at 6:25pm -0400,
>>> Kent Overstreet wrote:
>>>
Jens - this series does the rest of the conversions that Christoph wanted,
On Mon, May 21 2018 at 11:09am -0400,
Jens Axboe wrote:
> On 5/21/18 9:04 AM, Mike Snitzer wrote:
> > On Mon, May 21 2018 at 10:52am -0400,
> > Jens Axboe wrote:
> >
> >> On 5/21/18 8:47 AM, Mike Snitzer wrote:
> >>> On Mon, May 21 2018 at 10:36am -0400,
> >>> Jens Axboe wrote:
> >>>
> On
On Mon, May 21, 2018 at 08:19:58AM -0600, Jens Axboe wrote:
> On 5/21/18 8:03 AM, Mike Snitzer wrote:
> > On Sun, May 20 2018 at 6:25pm -0400,
> > Kent Overstreet wrote:
> >
> >> Jens - this series does the rest of the conversions that Christoph wanted,
> >> and
> >> drops bioset_create().
> >>
On 5/21/18 9:04 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:52am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 8:47 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:36am -0400,
>>> Jens Axboe wrote:
>>>
On 5/21/18 8:31 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:19am -
On Mon, May 21 2018 at 10:52am -0400,
Jens Axboe wrote:
> On 5/21/18 8:47 AM, Mike Snitzer wrote:
> > On Mon, May 21 2018 at 10:36am -0400,
> > Jens Axboe wrote:
> >
> >> On 5/21/18 8:31 AM, Mike Snitzer wrote:
> >>> On Mon, May 21 2018 at 10:19am -0400,
> >>> Jens Axboe wrote:
> >>>
> On
NOT FOR MERGING -- requires kernel versioning
Fixes EXTXBSY races.
Signed-off-by: Adam Borowski
---
cmds-filesystem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 30a50bf5..7eb6b7bb 100644
--- a/cmds-filesystem.c
+++ b/cmds-
On 5/21/18 8:47 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:36am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 8:31 AM, Mike Snitzer wrote:
>>> On Mon, May 21 2018 at 10:19am -0400,
>>> Jens Axboe wrote:
>>>
On 5/21/18 8:03 AM, Mike Snitzer wrote:
> On Sun, May 20 2018 at 6:25pm -
On Mon, May 21 2018 at 10:36am -0400,
Jens Axboe wrote:
> On 5/21/18 8:31 AM, Mike Snitzer wrote:
> > On Mon, May 21 2018 at 10:19am -0400,
> > Jens Axboe wrote:
> >
> >> On 5/21/18 8:03 AM, Mike Snitzer wrote:
> >>> On Sun, May 20 2018 at 6:25pm -0400,
> >>> Kent Overstreet wrote:
> >>>
> >>
We give EINVAL when the request is invalid; here it's ok but merely the
user has insufficient privileges. Thus, this return value reflects the
error better -- as discussed in the identical case for dedupe.
According to codesearch.debian.net, no userspace program distinguishes
these values beyond
Requiring a rw descriptor conflicts both ways with exec, returning ETXTBSY
whenever you try to defrag a program that's currently being run, or
causing intermittent exec failures on a live system being defragged.
As defrag doesn't change the file's contents in any way, there's no reason
to consider
Hi!
Here's a patch to fix ETXTBSY races between defrag and exec -- similar to
what was just submitted for dedupe, even to the point of being followed by
a second patch that replaces EINVAL with EPERM.
As defrag is not something you're going to do on files you don't write, I
skipped complex rules a
On 5/21/18 8:31 AM, Mike Snitzer wrote:
> On Mon, May 21 2018 at 10:19am -0400,
> Jens Axboe wrote:
>
>> On 5/21/18 8:03 AM, Mike Snitzer wrote:
>>> On Sun, May 20 2018 at 6:25pm -0400,
>>> Kent Overstreet wrote:
>>>
Jens - this series does the rest of the conversions that Christoph wanted
On Mon, May 21 2018 at 10:19am -0400,
Jens Axboe wrote:
> On 5/21/18 8:03 AM, Mike Snitzer wrote:
> > On Sun, May 20 2018 at 6:25pm -0400,
> > Kent Overstreet wrote:
> >
> >> Jens - this series does the rest of the conversions that Christoph wanted,
> >> and
> >> drops bioset_create().
> >>
>
On 5/20/18 4:25 PM, Kent Overstreet wrote:
> Jens - this series does the rest of the conversions that Christoph wanted, and
> drops bioset_create().
>
> Only lightly tested, but the changes are pretty mechanical. Based on your
> for-next tree.
Looks good to me. I'll let it simmer for a bit to giv
On 5/21/18 8:03 AM, Mike Snitzer wrote:
> On Sun, May 20 2018 at 6:25pm -0400,
> Kent Overstreet wrote:
>
>> Jens - this series does the rest of the conversions that Christoph wanted,
>> and
>> drops bioset_create().
>>
>> Only lightly tested, but the changes are pretty mechanical. Based on you
On Sun, May 20 2018 at 6:25pm -0400,
Kent Overstreet wrote:
> Jens - this series does the rest of the conversions that Christoph wanted, and
> drops bioset_create().
>
> Only lightly tested, but the changes are pretty mechanical. Based on your
> for-next tree.
By switching 'mempool_t *' to 'me
On domenica 20 maggio 2018 12:59:28 CEST, Tomasz Pala wrote:
On Sat, May 19, 2018 at 10:56:32 +0200, Niccol? Belli wrote:
snapper users with hourly snapshots will not have any use for it.
Anyone with hourly snapshots anyone is doomed anyway.
I do not agree: having hourly snapshots doesn't mea
пн, 21 мая 2018 г. в 16:16, Austin S. Hemmelgarn :
> On 2018-05-19 04:54, Niccolò Belli wrote:
> > On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote:
> >> With a bit of work, it's possible to handle things sanely. You can
> >> deduplicate data from snapshots, even if they are re
On 2018-05-19 04:54, Niccolò Belli wrote:
On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote:
With a bit of work, it's possible to handle things sanely. You can
deduplicate data from snapshots, even if they are read-only (you need
to pass the `-A` option to duperemove and run
On Fri, May 18, 2018 at 02:57:27PM -0700, Mark Fasheh wrote:
> Right now we return EINVAL if a process does not have permission to dedupe a
> file. This was an oversight on my part. EPERM gives a true description of
> the nature of our error, and EINVAL is already used for the case that the
> files
On 21.05.2018 12:32, Gu Jinxiang wrote:
> Since add_excluded_extent always returns 0,
> no need to judge ret.
This patch is conceptually wrong because:
a). Currently exclude_super_stripes is in fact buggy since it calls
set_extent_bits which *may* fail, yet the return value is completely
ignore
Since add_excluded_extent always returns 0,
no need to judge ret.
Signed-off-by: Gu Jinxiang
---
fs/btrfs/extent-tree.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 75cfb80d2551..4d876b32e136 100644
--- a/fs/btrfs/extent-tree.c
++
This function already takes a transaction handle which contains a
reference to the fs_info. So use this and remove the extra argument.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/b
Instead of setting "parent" to ref->parent only when dealing with
a shared ref and subsequently performing another check to see
if (parent > 0), check the "node->type" directly and act accordingly.
This makes the code more streamline. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/
This function currently takes 7 parameters, most of which are
proxies for values from btrfs_delayed_ref_node struct which is not
passed. This patch simplifies the interface of the function by
simply passing said delayed ref node struct to the function. This
enables us to:
1. Move locals variables
Instead of taking only specific member of this structure, which results
in 2 extra arguments, just take the delayed_extent_op struct and
reference the arguments inside the functions. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 11 +--
1 file changed
At the moment alloc_reserved_tree_block takes 8 friggin arguments. The irony
is that all of those are really derived from 3 structures. This series ends up
reducing the arguments to 3. As a result some code, private to
alloc_reserved_tree_block
is moved from run_delayed_tree_ref. Patch 1 removes
On 19.05.2018 00:43, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Jun Wu at Facebook reported that an internal service was seeing a return
> value of 1 from ftruncate() on Btrfs when compression is enabled. This
> is coming from the NEED_TRUNCATE_BLOCK return value from
> btrfs_truncate_inode
64 matches
Mail list logo
