Try to punch hole with unaligned size and offset when the FS
returns ENOSPC.
Signed-off-by: Anand Jain
---
v1->v2: Use at least 256MB to test.
This test case fails on btrfs as of now.
tests/btrfs/172 | 66 +
tests/btrfs/172.out | 2 ++
te
On 09/26/2018 02:34 PM, Nikolay Borisov wrote:
On 26.09.2018 07:07, Anand Jain wrote:
On 09/25/2018 06:51 PM, Nikolay Borisov wrote:
On 25.09.2018 07:24, Anand Jain wrote:
As of now _scratch_mkfs_sized() checks if the requested size is below 1G
and forces the --mixed option for the mk
On 26.09.2018 07:07, Anand Jain wrote:
>
>
> On 09/25/2018 06:51 PM, Nikolay Borisov wrote:
>>
>>
>> On 25.09.2018 07:24, Anand Jain wrote:
>>> As of now _scratch_mkfs_sized() checks if the requested size is below 1G
>>> and forces the --mixed option for the mkfs.btrfs. Well the correct size
>
On 09/25/2018 06:54 PM, Nikolay Borisov wrote:
On 25.09.2018 07:24, Anand Jain wrote:
Open code helps to grep and find out parameter sent to the
_scratch_mkfs_sized here.
Signed-off-by: Anand Jain
IMO this is noise, you can just as simply do
"grep _scratch_mkfs_sized" and then open the
On 09/25/2018 06:51 PM, Nikolay Borisov wrote:
On 25.09.2018 07:24, Anand Jain wrote:
As of now _scratch_mkfs_sized() checks if the requested size is below 1G
and forces the --mixed option for the mkfs.btrfs. Well the correct size
considering all possible group profiles at which we need to
On Tue, Sep 25, 2018 at 11:30:11AM -0400, Josef Bacik wrote:
> @@ -1454,6 +1463,11 @@ static inline int fixup_user_fault(struct task_struct
> *tsk,
> BUG();
> return -EFAULT;
> }
> +stiatc inline struct file *maybe_unlock_mmap_for_io(struct vm_area_struct
> *vma,
> +
On Tue, Sep 25, 2018 at 11:30:04AM -0400, Josef Bacik wrote:
> In preparation for caching pages during filemap faults we need to push
> the struct vm_fault up a level into the arch page fault handlers, since
> they are the ones responsible for retrying if we unlock the mmap_sem.
>
> Signed-off-by:
On 2018/9/25 下午11:34, David Sterba wrote:
> On Tue, Sep 25, 2018 at 08:06:26AM +0800, Qu Wenruo wrote:
>> Although BTRFS_NAME_LEN and XATTR_NAME_MAX is the same value (255),
>> max(BTRFS_NAME_LEN, XATTR_NAME_MAX) should be optimized as const at
>> runtime.
>>
>> However S390x' arch dependent opti
On Wed, Sep 19, 2018 at 08:40:40PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
> disks (up to two) are missing. This code use the md RAID 6 code already
> present in grub.
>
> Signed-off-by: Goffredo Ba
On Wed, Sep 19, 2018 at 08:40:38PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Add support for recovery for a RAID 5 btrfs profile. In addition
> it is added some code as preparatory work for RAID 6 recovery code.
>
> Signed-off-by: Goffredo Baroncelli
> ---
> grub-core/fs/
Currently btrfs raid1/10 balancer bаlance requests to mirrors,
based on pid % num of mirrors.
Make logic understood:
- if one of underline devices are non rotational
- Queue length to underline devices
By default try use pid % num_mirrors guessing, but:
- If one of mirrors are non rotational,
On Wed, Sep 19, 2018 at 08:40:35PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> If a device is not found, do not return immediately but
> record this failure by storing NULL in data->devices_attached[].
Still the same question: Where the store happens in the code?
I cannot fi
On Wed, Sep 19, 2018 at 08:40:34PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> The caller knows better if this error is fatal or not, i.e. another disk is
> available or not.
>
> This is a preparatory patch.
>
> Signed-off-by: Goffredo Baroncelli
> Reviewed-by: Daniel Kiper
On Tue, Sep 25, 2018 at 08:06:26AM +0800, Qu Wenruo wrote:
> Although BTRFS_NAME_LEN and XATTR_NAME_MAX is the same value (255),
> max(BTRFS_NAME_LEN, XATTR_NAME_MAX) should be optimized as const at
> runtime.
>
> However S390x' arch dependent option "-mwarn-dynamicstack" could still
> report it a
On Wed, Sep 19, 2018 at 08:40:32PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Signed-off-by: Goffredo Baroncelli
> ---
> grub-core/fs/btrfs.c | 66
> 1 file changed, 66 insertions(+)
>
> diff --git a/grub-core/fs/btrfs.c b/grub-
From: Johannes Weiner
Reads can take a long time, and if anybody needs to take a write lock on
the mmap_sem it'll block any subsequent readers to the mmap_sem while
the read is outstanding, which could cause long delays. Instead drop
the mmap_sem if we do any reads at all.
Signed-off-by: Johann
From: Johannes Weiner
We don't need to hold the mmap_sem while we're doing the IO, simply drop
it and retry appropriately.
Signed-off-by: Johannes Weiner
Signed-off-by: Josef Bacik
---
mm/page_io.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/mm/page_io.c b/mm/page_io.c
Johannes' patches didn't quite cover all of the IO cases that we need to
drop the mmap_sem for, this patch covers the rest of them.
Signed-off-by: Josef Bacik
---
mm/filemap.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index 1ed35cd99b2c..65395ee
From: Johannes Weiner
__read_swap_cache_async() has a misleading name. All it does is look
up or create a page in swapcache; it doesn't initiate any IO.
The swapcache has many parallels to the page cache, and shares naming
schemes with it elsewhere. Analogous to the cache lookup and creation
API
In preparation for caching pages during filemap faults we need to push
the struct vm_fault up a level into the arch page fault handlers, since
they are the ones responsible for retrying if we unlock the mmap_sem.
Signed-off-by: Josef Bacik
---
arch/alpha/mm/fault.c | 4 ++-
arch/arc/mm/
Now that we have proper isolation in place with cgroups2 we have started going
through and fixing the various priority inversions. Most are all gone now, but
this one is sort of weird since it's not necessarily a priority inversion that
happens within the kernel, but rather because of something us
This is preparation for dropping the mmap_sem in page_mkwrite. We need
to know if we used our cached page so we can be sure it is the page we
already did the page_mkwrite stuff on so we don't have to redo all of
that work.
Signed-off-by: Josef Bacik
---
include/linux/mm.h | 6 +-
mm/filemap
If we drop the mmap_sem we need to redo the vma lookup and then
re-lookup the page. This is kind of a waste since we've already done
the work, and we could even possibly evict the page, causing a refault.
Instead just hold a reference to the page and save it in our vm_fault.
The next time we go th
->page_mkwrite is extremely expensive in btrfs. We have to reserve
space, which can take 6 lifetimes, and we could possibly have to wait on
writeback on the page, another several lifetimes. To avoid this simply
drop the mmap_sem if we didn't have the cached page and do all of our
work and return
On Tue, Sep 25, 2018 at 08:06:25AM +0800, Qu Wenruo wrote:
> Since we're following the name size limit of linux, just use NAME_MAX.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btrfs/ctree.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
On Tue, Sep 25, 2018 at 02:37:46PM +0800, Qu Wenruo wrote:
> fs/btrfs/relocation.c:build_backref_tree() is some code from 2009 era,
> although it works pretty fine, it's not that easy to understand.
> Especially combined with the complex btrfs backref format.
>
> This patch adds some basic comment
On 25.09.2018 07:24, Anand Jain wrote:
> commit 97575acd7495 (generic/015: Change the test filesystem size to
> 101mb), created 101mb FS instead of 100mb FS to make sure we create
> a FS which is non mixed mode.
>
> btrfs-progs commit 18e2663db3e1 (btrfs-progs: Add minimum device size
> check)
On 25.09.2018 07:24, Anand Jain wrote:
> Open code helps to grep and find out parameter sent to the
> _scratch_mkfs_sized here.
>
> Signed-off-by: Anand Jain
IMO this is noise, you can just as simply do
"grep _scratch_mkfs_sized" and then open the file to inspect the actual
argument. But it's
On 25.09.2018 07:24, Anand Jain wrote:
> As of now _scratch_mkfs_sized() checks if the requested size is below 1G
> and forces the --mixed option for the mkfs.btrfs. Well the correct size
> considering all possible group profiles at which we need to force the
> mixed option is roughly 256Mbytes.
On Mon, Sep 24, 2018 at 03:16:55PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> The only aops we define for symlinks are identical to the aops for
> regular files. This has been the case since symlink support was added in
> commit 2b8d99a723a3 ("Btrfs: symlinks and hard links"). As far a
在 2018年09月25日 16:31, Nikolay Borisov 写道:
On 25.09.2018 11:20, sunny.s.zhang wrote:
在 2018年09月20日 02:36, Liu Bo 写道:
On Mon, Sep 17, 2018 at 5:28 PM, sunny.s.zhang
wrote:
Hi All,
My OS(4.1.12) panic in kmem_cache_alloc, which is called by
btrfs_get_or_create_delayed_node.
I found that the
On 25.09.2018 11:20, sunny.s.zhang wrote:
>
> 在 2018年09月20日 02:36, Liu Bo 写道:
>> On Mon, Sep 17, 2018 at 5:28 PM, sunny.s.zhang
>> wrote:
>>> Hi All,
>>>
>>> My OS(4.1.12) panic in kmem_cache_alloc, which is called by
>>> btrfs_get_or_create_delayed_node.
>>>
>>> I found that the freelist of t
在 2018年09月20日 00:12, Nikolay Borisov 写道:
On 19.09.2018 02:53, sunny.s.zhang wrote:
Hi Duncan,
Thank you for your advice. I understand what you mean. But i have
reviewed the latest btrfs code, and i think the issue is exist still.
At 71 line, if the function of btrfs_get_delayed_node run ove
在 2018年09月20日 02:36, Liu Bo 写道:
On Mon, Sep 17, 2018 at 5:28 PM, sunny.s.zhang wrote:
Hi All,
My OS(4.1.12) panic in kmem_cache_alloc, which is called by
btrfs_get_or_create_delayed_node.
I found that the freelist of the slub is wrong.
crash> struct kmem_cache_cpu 887e7d7a24b0
struct
34 matches
Mail list logo
