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 16:13, Chao Yu wrote:
>>> f2fs doesn't a
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?
>
> On 2018/2/27 22:16, Chao Yu wrote:
> > Ping,
> >
> > On 2018/2/13 15:34, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2018/2/10 10:
On Mon, Apr 16, 2018 at 7:07 PM, Dave Chinner wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>> Thanks! As I mentioned before, this is useful. I have a follow-up
>> question. Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
>> fsync(foo)
>> cra
On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
> Thanks! As I mentioned before, this is useful. I have a follow-up
> question. Consider the following workload:
>
> creat foo
> link (foo, A/bar)
> fsync(foo)
> crash
>
> In this case, after the file system recovers, do we ex
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 take on the
argument that one should verify before performing any other
cryptographic ope
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 16:13, Chao Yu wrote:
> > f2fs doesn't allow abuse on atomic write class interfac
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 postprocessing steps such as
authenticity verific
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 either by itself, or combined with decryption.
To support this, store a
Hello,
These two patches restructure f2fs's read path to allow the data to go
through multiple postprocessing steps, rather than just decryption as is
implemented currently. This is mainly in preparation for doing
authenticity verification of data via fs-verity, though this change
might also be u
On Sat, Apr 14, 2018 at 07:12:13AM -0700, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> This conversion keeps the radix tree and XArray data structures in sync
> at all times. That allows us to convert the page cache one function at
> a time and should allow for easier bisection. Other than
On Mon, Apr 16, 2018 at 12:39 AM, Amir Goldstein wrote:
> On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram
> wrote:
> [...]
>> Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
>> fsync(foo)
>> crash
>>
>> In this case, after the file system recovers, do we expect foo's
On Mon, Apr 16, 2018 at 12:52 AM, Theodore Y. Ts'o wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>>
>> I don't think this is what the paper's ext3-fast does. All the paper
>> says is if you have a file system where the fsync of a file persisted
>> only data related to
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 insertions(+), 16 deletions(-)
diff --git a/fs/f2fs/s
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/f2fs/file.c b/fs/f2fs/file.c
index 79eeed5..bf61e20 10064
14 matches
Mail list logo