On Wed, Jul 28, 2021 at 09:37:28PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Document all fields of struct fscrypt_operations so that it's more clear
> what filesystems that use (or plan to use) fs/crypto/ need to implement.
>
> Signed-off-by: Eric Biggers
> ---
> include/linux/fscry
From: Daeho Jeong
Added a mount option to control block allocation mode for filesystem
developer to simulate filesystem fragmentation and after-GC situation
for experimental reasons to understand the filesystem behaviors well
under the severe condition. This supports "normal", "seg_random" and
"b
On 8/6/21 1:18 PM, Damien Le Moal wrote:
> The BFQ scheduler and ioprio_check_cap() both assume that the RT
> priority class (IOPRIO_CLASS_RT) can have up to 8 different priority
> levels. This is controlled using the macro IOPRIO_BE_NR, which is badly
> named as the number of levels also applies t
The BFQ scheduler and ioprio_check_cap() both assume that the RT
priority class (IOPRIO_CLASS_RT) can have up to 8 different priority
levels. This is controlled using the macro IOPRIO_BE_NR, which is badly
named as the number of levels also applies to the RT class.
Rename IOPRIO_BE_NR to the class
An iocb aio_reqprio field is 16-bits (u16) but often handled as an int
in the block layer. E.g. ioprio_check_cap() takes an int as argument.
With such implicit int casting function calls, the upper 16-bits of the
int argument may be left uninitialized by the compiler, resulting in
invalid values fo
This series fixes problems with IO priority values handling and cleans
up several macro names and code for clarity.
Changes from v2:
* Fixed typo in a comment in patch 3
* Added reviewed-by tags
Changes from v1:
* Added patch 4 to unify the default priority value used in various
places.
* Fixed
For a request that has a priority level equal to or larger than
IOPRIO_BE_NR, bfq_set_next_ioprio_data() prints a critical warning but
defaults to setting the request new_ioprio field to IOPRIO_BE_NR. This
is not consistent with the warning and the allowed values for priority
levels. Fix this by se
The default IO priority is the best effort (BE) class with the
normal priority level IOPRIO_NORM (4). However, get_task_ioprio()
returns IOPRIO_CLASS_NONE/IOPRIO_NORM as the default priority and
get_current_ioprio() returns IOPRIO_CLASS_NONE/0. Let's be consistent
with the defined default and have
For compressed file, after release compress blocks, don't allow write
direct, but we should allow write direct after truncate to zero.
Signed-off-by: Fengnan Chang
---
Documentation/filesystems/f2fs.rst | 7 +--
fs/f2fs/file.c | 8
2 files changed, 13 insertions(
This patch supports to inject fault into f2fs_kmem_cache_alloc().
Usage:
a) echo 32768 > /sys/fs/f2fs//inject_type or
b) mount -o fault_type=32768
Signed-off-by: Chao Yu
---
v2:
- fix to use FAULT_SLAB_ALLOC correctly.
Documentation/filesystems/f2fs.rst | 1 +
fs/f2fs/checkpoint.c
On 2021/8/6 16:35, Fengnan Chang wrote:
Um.. I think this version should be ok.
Well, actually, I mean adding description of this behavior into compression
section of f2fs.rst.
https://elixir.bootlin.com/linux/latest/source/Documentation/filesystems/f2fs.rst#L829
Thanks,
Thanks.
On 2021/7
On 8/6/21 8:57 AM, Damien Le Moal wrote:
> On 2021/08/06 15:35, Hannes Reinecke wrote:
>> On 8/6/21 7:11 AM, Damien Le Moal wrote:
>>> An iocb aio_reqprio field is 16-bits (u16) but often handled as an int
>>> in the block layer. E.g. ioprio_check_cap() takes an int as argument.
>>> With such impli
Um.. I think this version should be ok.
Thanks.
On 2021/7/23 10:31, Fengnan Chang wrote:
For compressed file, after release compress blocks, don't allow write
direct, but we should allow write direct after truncate to zero.
Signed-off-by: Fengnan Chang
---
fs/f2fs/file.c | 8
1 fi
I'll check this later.
Thanks.
On 2021/8/6 8:57, Chao Yu wrote:
On 2021/7/23 11:18, Fengnan Chang wrote:
f2fs_read_multi_pages will handle，all truncate page will be zero out,
Whether partial or all page in cluster.
On 2021/7/22 21:47, Chao Yu wrote:
On 2021/7/22 11:25, Fengnan Chang wrote:
On 2021/08/06 15:35, Hannes Reinecke wrote:
> On 8/6/21 7:11 AM, Damien Le Moal wrote:
>> An iocb aio_reqprio field is 16-bits (u16) but often handled as an int
>> in the block layer. E.g. ioprio_check_cap() takes an int as argument.
>> With such implicit int casting function calls, the upper 16-bi
15 matches
Mail list logo
