On 2018/4/18 11:06, Yunlei He wrote:
> If a file not set type as hot, has dirty pages more than
> threshold 64 before starting atomic write, may be lose hot
> flag.
>
> v1->v2: move set FI_ATOMIC_FILE flag behind flush dirty pages too,
> in case of dirty pages before starting atomic use atomic mod
Hi Eric,
On 2018/4/18 1:42, Eric Biggers wrote:
> Hi Chao,
>
> On Tue, Apr 17, 2018 at 05:13:12PM +0800, Chao Yu wrote:
>>> +
>>> +static void bio_post_read_processing(struct bio_post_read_ctx *ctx);
>>> +
>>> +static void decrypt_work(struct work_struct *work)
>>> +{
>>> + struct bio_post_read
On 04/16, Eric Biggers wrote:
> Currently, fscrypt provides fscrypt_decrypt_bio_pages() which decrypts a
> bio's pages asynchronously, then unlocks them afterwards. But, this
> assumes that decryption is the last "postprocessing step" for the bio,
> so it's incompatible with additional postprocess
On 04/17, Chao Yu wrote:
> On 2018/4/17 14:44, Chao Yu wrote:
> > On 2018/4/17 4:16, Jaegeuk Kim wrote:
> >> On 04/13, Chao Yu wrote:
> >>> On 2018/4/13 12:05, Jaegeuk Kim wrote:
> On 04/13, Chao Yu wrote:
> > On 2018/4/13 9:04, Jaegeuk Kim wrote:
> >> On 04/10, Chao Yu wrote:
> >>
If a file not set type as hot, has dirty pages more than
threshold 64 before starting atomic write, may be lose hot
flag.
v1->v2: move set FI_ATOMIC_FILE flag behind flush dirty pages too,
in case of dirty pages before starting atomic use atomic mode to
write back.
Signed-off-by: Yunlei He
---
On 04/14/2018 02:58 PM, Matthew Wilcox wrote:
> On Sat, Apr 14, 2018 at 12:50:30PM -0700, Matthew Wilcox wrote:
>> On Mon, Apr 09, 2018 at 04:18:07PM -0500, Goldwyn Rodrigues wrote:
>>
>> I'm sorry I missed this email. My inbox is a disaster :(
>>
>>> I tried these patches against next-20180329
Hi Chao,
On Tue, Apr 17, 2018 at 05:13:12PM +0800, Chao Yu wrote:
> > +
> > +static void bio_post_read_processing(struct bio_post_read_ctx *ctx);
> > +
> > +static void decrypt_work(struct work_struct *work)
> > +{
> > + struct bio_post_read_ctx *ctx =
> > + container_of(work, struct b
Hi Michael,
On Mon, Apr 16, 2018 at 03:15:42PM -0700, Michael Halcrow wrote:
> Given recent talk I've seen on potentially applying file-based
> protections in NFS, I think it's worth making some cautionary
> observations at this stage.
>
> Moxie's Cryptographic Doom Principle is an approachable t
On 2018/4/17 11:38, Jaegeuk Kim wrote:
> On 04/13, Chao Yu wrote:
>> Ping again..
>>
>> Do you have time to discuss this?
>
> We may need a time to have a chat in person. Do you have any chance to visit
> US?
I prefer to, just count on LSF, but...
I think I need to find a conference which is ope
On 2018/4/17 14:44, Chao Yu wrote:
> On 2018/4/17 4:16, Jaegeuk Kim wrote:
>> On 04/13, Chao Yu wrote:
>>> On 2018/4/13 12:05, Jaegeuk Kim wrote:
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:04, Jaegeuk Kim wrote:
>> On 04/10, Chao Yu wrote:
>>> Hi Jaegeuk,
>>>
>>> On 2018/4/8
On 2018/4/17 17:12, Sheng Yong wrote:
> `cur' will never be NULL, we should check inmem_pages list instead.
>
> Signed-off-by: Sheng Yong
Reviewed-by: Chao Yu
Thanks,
> ---
> fs/f2fs/segment.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2
On 2018/4/17 17:14, heyunlei wrote:
>
>
>> -Original Message-
>> From: Yuchao (T)
>> Sent: Tuesday, April 17, 2018 4:31 PM
>> To: heyunlei; jaeg...@kernel.org; linux-f2fs-devel@lists.sourceforge.net
>> Cc: Wangbintian; Zhangdianfang (Euler)
>> Subject: Re: [f2fs-dev][PATCH] f2fs: allocate
Thread GC thread
- f2fs_ioc_start_atomic_write
- get_dirty_pages
- filemap_write_and_wait_range
- f2fs_gc
- do_garbage_collect
- gc_data_segm
`cur' will never be NULL, we should check inmem_pages list instead.
Signed-off-by: Sheng Yong
---
fs/f2fs/segment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 5854cc4e1d67..bf9dab55b370 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f
>-Original Message-
>From: Yuchao (T)
>Sent: Tuesday, April 17, 2018 4:31 PM
>To: heyunlei; jaeg...@kernel.org; linux-f2fs-devel@lists.sourceforge.net
>Cc: Wangbintian; Zhangdianfang (Euler)
>Subject: Re: [f2fs-dev][PATCH] f2fs: allocate hot_data for atomic write more
>strictly
>
>On 201
On 2018/4/17 3:31, Eric Biggers via Linux-f2fs-devel wrote:
> Currently f2fs's ->readpage() and ->readpages() assume that either the
> data undergoes no postprocessing, or decryption only. But with
> fs-verity, there will be an additional authenticity verification step,
> and it may be needed eith
On 2018/4/16 19:34, Yunlei He wrote:
> If a file not set type as hot, has dirty pages more than
> threshold 64 before starting atomic write, may be lose hot
> flag.
>
> Signed-off-by: Yunlei He
> ---
> fs/f2fs/file.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/
On 2018/4/16 19:48, LiFan wrote:
> Copy summary entries in bulk in write_compacted_summaries().
> And zero the blank part of page after writing the summaries
> to the page.
>
> Signed-off-by: Fan li
> ---
> fs/f2fs/segment.c | 38 ++
> 1 file changed, 22 inser
18 matches
Mail list logo