ore
bifurcating the read/write DONTCACHE support?
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
On 7/30/25 8:35 PM, Chao Yu wrote:
> On 7/30/25 23:20, Jens Axboe wrote:
>> On 7/28/25 2:28 AM, hanqi wrote:
>>> ? 2025/7/28 16:07, Chao Yu ??:
>>>> On 7/28/25 16:03, hanqi wrote:
>>>>> ? 2025/7/28 15:38, Chao Yu ??:
>>>>>
>>>&
On 7/30/25 7:58 PM, hanqi wrote:
>
> ? 2025/7/30 23:20, Jens Axboe ??:
>> On 7/28/25 2:28 AM, hanqi wrote:
>>> ? 2025/7/28 16:07, Chao Yu ??:
>>>> On 7/28/25 16:03, hanqi wrote:
>>>>> ? 2025/7/28 15:38, Chao Yu ??:
>>>>>
>>&g
o
> As I understand it, if we don't set the FGP_DONTCACHE flag here, this
> issue shouldn't occur.
It won't cause an issue, but it also won't work in the sense that the
intent is that if the file system doesn't support DONT
On 7/15/25 9:34 PM, hanqi wrote:
>
>
> ? 2025/7/15 22:28, Jens Axboe ??:
>> On 7/14/25 9:10 PM, Qi Han wrote:
>>> Jens has already completed the development of uncached buffered I/O
>>> in git [1], and in f2fs, the feature can be enabled simply by sett
ou want to see it remain basically flat in terms of page cache usage.
Maybe this is all fine, like I said I didn't verify. Just mentioning it
for completeness sake.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.
loc_bioset(), but null checking after
> bio_alloc_bioset() was still left.
Reviewed-by: Jens Axboe
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
return -EINVAL;
if (memchr_inv(rwh.pad, 0, sizeof(rwh.pad)))
return -EINVAL;
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
273d21ea1f212c6636f231d6d2771
[5/5] block: remove gfp_flags from blkdev_zone_mgmt
commit: 71f4ecdbb42addf82b01b734b122a02707fed521
Best regards,
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https:
5c55430a5674b32ad0d9e57a8ec251
Best regards,
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
t; to get some exposure in linux-next as well? Thanks!
For the block bits:
Acked-by: Jens Axboe
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
On 6/20/23 12:16?AM, Jaegeuk Kim wrote:
> On 06/19, Jens Axboe wrote:
>> Hi,
>>
>> I came across this patch in a news posting:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=d618126911829523e35a61f4a5a4ad159b1b2c8d
>
rted until f2fs is converted to iomap, or IOCB_NOWAIT is
handled by generic_perform_write() and below.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
data
commit: ee3249a8ce78ef014a71b05157a43fba8dc764e3
[30/30] fs: remove the now unused FMODE_* flags
commit: 0733ad8002916b9dbbbcfe6e92ad44d2657de1c1
Best regards,
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
ranularity helper
commit: 7b47ef52d0a2025fd1408a8a0990933b8e1e510f
[26/27] block: decouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD
commit: 44abff2c0b970ae3d310b97617525dc01f248d7c
[27/27] direct-io: remove random prefetches
commit: c22198e78d523c8fa079bbb70b2523bb6aa518
nups
> branch?
I have tentatively done so, let me know you prefer doing it differently.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
block patches can go through the
> respective trees proving the final patch doesn't land until after they
> all do - so maybe it should be held for 5.18-rc2 if all the rest lands
> by 5.18-rc1.
For the series:
Acked-by: Jens Axboe
--
Jens Axboe
__
On 11/10/21 12:08 PM, Jaegeuk Kim wrote:
> On 11/09, Jens Axboe wrote:
>> On 11/9/21 9:39 AM, Christoph Hellwig wrote:
>>> On Mon, Nov 08, 2021 at 06:13:36PM -0800, Jaegeuk Kim wrote:
>>>> This patch adds a way to attach HIPRI by expanding the existing sysfs's
g should only be used when explicitly specified by
> the submitter of the I/O.
Yes, this cannot be set in the middle for a multitude of reasons. I wonder
if we should add a comment to that effect near the definition of it.
--
Jens Axboe
___
Linux-f2fs-
om the 5.15
drivers branch anyway.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
/*
> - * 8 best effort priority levels are supported
> + * The RT and BE priority classes both support up to 8 priority levels.
> */
> -#define IOPRIO_BE_NR 8
> +#define IOPRIO_NR_LEVELS 8
That might not be a good idea, if an application alrea
t; - * Fallback BE priority
> + * Fallback BE priority level.
> */
> -#define IOPRIO_NORM 4
> +#define IOPRIO_BE_NORM 4
This again seems like a very poor idea.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux
looks fine to me. A better commit title
would do wonders too, though, it's very non-descript.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
On 1/26/21 7:52 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series contains various cleanups for how bios are allocated or
> initialized plus related fallout.
Applied, thanks.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linu
a two-parter:
1) Use the inode blkbits where appropriate
2) Then do this change
I'm leaning towards just doing it in blksize_bits() instead of updating
every caller, unless there aren't that many left once we've gone
through patch 1.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
message is
handwavy at best.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
ince patches 6-12 depend on them. Then patches 6-12 can go upstream
> via
> the SCSI and fscrypt trees in the following release.
I have applied 1-5 for 5.8. Small tweak needed in patch 3 due to a header
inclusion, but clean apart from that.
--
Jens Axboe
_
> series for inclusion in the 5.5 kernel.
We're taking branching to new levels... I created for-5.5/zoned for this,
which is for-5.5/block + for-5.5/drivers + for-5.5/drivers-post combined.
The latter is a branch with the SCSI dependencies from Martin pulled in.
--
Jens Axboe
h this, and the inline encryption
proposed by Google, we'll bloat the bio even more. At least the Google
approach didn't include bio iter changes as well.
Please work it out between yourselves so we can have a single, clean
abstraction that works for both.
--
Jens Axboe
(!blk_crypto_submit_bio(&bio))
> + ret = q->make_request_fn(q, bio);
>
> blk_queue_exit(q);
Why isn't this just stacking the ->make_request_fn() instead? Then we
could get this out of the hot path.
--
Jens Axboe
__
> +}
These WARN()'s are a bit weird.
> +static inline u64 bio_crypt_data_unit_num(struct bio *bio)
> +{
> + WARN_ON(1);
> + return 0;
> +}
And this one definitely needs to go.
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 95202f80676c.
On 7/11/19 8:05 PM, Jens Axboe wrote:
> On 7/7/19 8:02 PM, Damien Le Moal wrote:
>> On 2019/07/01 14:09, Damien Le Moal wrote:
>>> This series addresses a recuring problem with zone revalidation
>>> failures observed during extensive testing with memory constraine
s, Martin,
>
> Any comment regarding this series ?
LGTM, I'll queue it up for this release.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
s first two pages on loop file
> 2) LOOP_SET_STATUS64 changes the offset on the loop file
> 3) mount is failed due to the cached pages having wrong superblock
Applied, thanks.
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@l
On 12/18/18 10:25 AM, Jaegeuk Kim wrote:
> This patch makes dm be aware of io_pages to assign sane req_size for reads.
Reviewed-by: Jens Axboe
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
ht
On 10/16/18 1:31 PM, Jaegeuk Kim wrote:
> On 10/16, Jens Axboe wrote:
>> On 10/16/18 1:23 PM, Jaegeuk Kim wrote:
>>> Thanks Jens,
>>>
>>> On top of the patch killing the dead code, I wrote another one to detect
>>> the idle time by the internal account
t's what got us into trouble in the first place. Can I add
your acked-by or review-by to the other patch, then?
--
Jens Axboe
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
On 10/16/18 10:06 AM, Chao Yu wrote:
> Hi Jens,
>
> On 2018-10-16 22:34, Jens Axboe wrote:
>> This doesn't work on stacked devices, and it doesn't work on
>> blk-mq devices. The request_list is only used on legacy, which
>> we don't have much of anymore,
This doesn't work on stacked devices, and it doesn't work on
blk-mq devices. The request_list is only used on legacy, which
we don't have much of anymore, and soon won't have any of.
Kill the check.
Cc: Jaegeuk Kim
Cc: linux-f2fs-devel@lists.sourceforge.net
Signed-off-by:
On 07/27/2016 12:46 PM, Linus Torvalds wrote:
> On Wed, Jul 27, 2016 at 11:29 AM, Jens Axboe wrote:
>>
>> Looks OK to me, though I think you could have dropped the ->bi_rw
>> assignment in f2fs_submit_page_bio():
>>
>> bio->bi_rw = fio->op_flags
bio_set_op_attrs(bio, fio->op, fio->op_flags);
__submit_bio(fio->sbi, bio, fio->type);
--
Jens Axboe
--
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
41 matches
Mail list logo
