Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 1:11 PM, Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 12:16:11PM -0700, Dan Williams wrote: >> Silently turn on DAX if HMAT says its ok? > > Yes, absolutely. I want my system to do the right thing by default, > and if HMAT says bypassing the page cache is a clear advatange it > should be the default. > >> I think we would instead >> want a "-o autodax" for that case and then "-o dax" and "-o nodax" for >> the force cases. > > Why? > I'm worried about the case where HMAT says pmem >= dram performance, but dax semantics like disabling delayed allocation and dirty-cacheline tracking end up hurting performance, but I guess we can handle that on a case by case basis with targeted kernel optimizations. >> I think it's easier to administer than the dax mount option. If >> someone wants dax on only in a sub-tree they can set the flag on that >> parent directory and have a policy in dax filesystems that children >> inherit the dax policy from the parent. That seems a better >> administrative model than trying to get it all right globally at mount >> time. > > And why exactly? If DAX is faster for file a in directory X it will > be just as fast for a file b in directory Y. So I want the inode setting for the pmem < dram performance case where I know that access patterns of the application using file b in directory Y can still yield better performance without page cache. For example, the working set is larger than dram capacity.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 12:16:11PM -0700, Dan Williams wrote: > Silently turn on DAX if HMAT says its ok? Yes, absolutely. I want my system to do the right thing by default, and if HMAT says bypassing the page cache is a clear advatange it should be the default. > I think we would instead > want a "-o autodax" for that case and then "-o dax" and "-o nodax" for > the force cases. Why? > I think it's easier to administer than the dax mount option. If > someone wants dax on only in a sub-tree they can set the flag on that > parent directory and have a policy in dax filesystems that children > inherit the dax policy from the parent. That seems a better > administrative model than trying to get it all right globally at mount > time. And why exactly? If DAX is faster for file a in directory X it will be just as fast for a file b in directory Y.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 10:20 AM, Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 10:11:08AM -0700, Dan Williams wrote: >> Until HMAT came along we had no data in the kernel how to pick a sane >> default, but we could now very easily make a "if pmem performance < >> dram, disable dax by default" policy in the kernel. > > I'd rather do it the other way around - if HMAT is present and > pmem performance >= dram use dax. Else require the explicit -o dax > for now to enable it. If an explicit -o nodax is specified disable > DAX even if HMAT says it is faster. Silently turn on DAX if HMAT says its ok? I think we would instead want a "-o autodax" for that case and then "-o dax" and "-o nodax" for the force cases. >> The question for this patch is do we want to add yet another >> filesystem that adds "-o dax" or require use of per-inode flags to >> enable dax. > > Please stick to the mount option. After spending a lot of time with > DAX and various memory techologies I'm pretty confident that the inode > flag is the wrong thing to do. I think it's easier to administer than the dax mount option. If someone wants dax on only in a sub-tree they can set the flag on that parent directory and have a policy in dax filesystems that children inherit the dax policy from the parent. That seems a better administrative model than trying to get it all right globally at mount time.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 10:11:08AM -0700, Dan Williams wrote: > Until HMAT came along we had no data in the kernel how to pick a sane > default, but we could now very easily make a "if pmem performance < > dram, disable dax by default" policy in the kernel. I'd rather do it the other way around - if HMAT is present and pmem performance >= dram use dax. Else require the explicit -o dax for now to enable it. If an explicit -o nodax is specified disable DAX even if HMAT says it is faster. > The question for this patch is do we want to add yet another > filesystem that adds "-o dax" or require use of per-inode flags to > enable dax. Please stick to the mount option. After spending a lot of time with DAX and various memory techologies I'm pretty confident that the inode flag is the wrong thing to do.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 10:01 AM, Christoph Hellwig wrote: > On Wed, Jul 26, 2017 at 09:53:07AM -0700, Dan Williams wrote: >> It allows for opt-in for applications, or administrators of those >> applications, that know the type of access. > > That's BS. We need to provide the best possible way to access the > media to an application. And whether that's DAX or the page cache > is an implementation detail that should not matter to the application. > > Which doesn't mean there shouldn't be ways to override the default > that the kernel chose based on hardware details, but it's certainly > not something for the application to hardcode, but something for > the adminstrator to decide. Until HMAT came along we had no data in the kernel how to pick a sane default, but we could now very easily make a "if pmem performance < dram, disable dax by default" policy in the kernel. The question for this patch is do we want to add yet another filesystem that adds "-o dax" or require use of per-inode flags to enable dax.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 09:53:07AM -0700, Dan Williams wrote: > It allows for opt-in for applications, or administrators of those > applications, that know the type of access. That's BS. We need to provide the best possible way to access the media to an application. And whether that's DAX or the page cache is an implementation detail that should not matter to the application. Which doesn't mean there shouldn't be ways to override the default that the kernel chose based on hardware details, but it's certainly not something for the application to hardcode, but something for the adminstrator to decide.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Wed, Jul 26, 2017 at 12:26 AM, Christoph Hellwig wrote: > On Tue, Jul 25, 2017 at 05:15:10PM -0700, Dan Williams wrote: >> We're in the process of walking back and potentially deprecating the >> use of the dax mount option for xfs and ext4 since dax can have >> negative performance implications if page cache memory happens to be >> faster than pmem. It should be limited to applications that >> specifically want the semantic, not globally enabled for the entire >> mount. xfs has went ahead and added the XFS_DIFLAG2_DAX indoe flag for >> per-inode enabling of dax. >> >> I'm wondering if any new filesystem that adds dax support at this >> point should do so with inode flags and not a mount option? > > That tradeoff is not one that the application should make, but one that > should depend on the storage medium. To make things worse it might also > depend on the type of access. E.g. with certain media it makes a lot of > sense to cache writes in the page cache, but generally not reads. > I've been spending some time to analyze how that could be done, but > I've not made real progress on it. > > XFS_DIFLAG2_DAX is unfortunately totally unhelpful with that. It allows for opt-in for applications, or administrators of those applications, that know the type of access. There's also the new HMAT (heterogeneous memory attributes table) in ACPI that can indicate the relative performance of pmem to system-ram if userspace needs data to make a decision. It would be interesting to have an automatic policy in the kernel, but we also need a mechanism for explicit configurations.
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
On Tue, Jul 25, 2017 at 05:15:10PM -0700, Dan Williams wrote: > We're in the process of walking back and potentially deprecating the > use of the dax mount option for xfs and ext4 since dax can have > negative performance implications if page cache memory happens to be > faster than pmem. It should be limited to applications that > specifically want the semantic, not globally enabled for the entire > mount. xfs has went ahead and added the XFS_DIFLAG2_DAX indoe flag for > per-inode enabling of dax. > > I'm wondering if any new filesystem that adds dax support at this > point should do so with inode flags and not a mount option? That tradeoff is not one that the application should make, but one that should depend on the storage medium. To make things worse it might also depend on the type of access. E.g. with certain media it makes a lot of sense to cache writes in the page cache, but generally not reads. I've been spending some time to analyze how that could be done, but I've not made real progress on it. XFS_DIFLAG2_DAX is unfortunately totally unhelpful with that.
RE: [PATCH v8 1/1] f2fs: dax: implement direct access
Hi, Considering the current interfaces of F2FS and EXT4, my thought is that we can define a generic user-modifiable flag FS_DAX_FL, which can be included in the i_flags field of [f2fs | ext4]_inode_info. Thus, DAX can be enabled in either of the two ways below: 1) mount the FS with a "dax" option, so that all files created will have the flag S_DAX set in the VFS inode, and the flag FS_DAX_FL set in [f2fs | ext4]_inode_info, by default. 2) mount the FS without "dax", and enable DAX per-inode from f2fs_ioctl_setflags() => f2fs_set_inode_flags() Thanks, From: Jaegeuk Kim [jaeg...@kernel.org] Sent: Wednesday, July 26, 2017 10:16 To: Dan Williams Cc: sunqiuyang; Linux Kernel Mailing List; linux-fsdevel; linux-f2fs-de...@lists.sourceforge.net; linux-nvd...@lists.01.org Subject: Re: [PATCH v8 1/1] f2fs: dax: implement direct access Hi Dan, On 07/25, Dan Williams wrote: > [ adding linux-nvdimm ] > > On Thu, Jul 20, 2017 at 5:10 AM, sunqiuyang wrote: > > From: Qiuyang Sun > > > > This patch implements Direct Access (DAX) in F2FS, including: > > - a mount option to choose whether to enable DAX or not > > We're in the process of walking back and potentially deprecating the > use of the dax mount option for xfs and ext4 since dax can have > negative performance implications if page cache memory happens to be > faster than pmem. It should be limited to applications that > specifically want the semantic, not globally enabled for the entire > mount. xfs has went ahead and added the XFS_DIFLAG2_DAX indoe flag for > per-inode enabling of dax. Thank you so much for pointing this out. So, is there a plan to define a generic inode flag to enable dax via inode_set_flag? Or, does each filesystem need to handle it individually likewise xfs? > > I'm wondering if any new filesystem that adds dax support at this > point should do so with inode flags and not a mount option? Anyway, in such the case, I have to postpone merging this patch for a while. Thanks,
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
Hi Dan, On 07/25, Dan Williams wrote: > [ adding linux-nvdimm ] > > On Thu, Jul 20, 2017 at 5:10 AM, sunqiuyang wrote: > > From: Qiuyang Sun > > > > This patch implements Direct Access (DAX) in F2FS, including: > > - a mount option to choose whether to enable DAX or not > > We're in the process of walking back and potentially deprecating the > use of the dax mount option for xfs and ext4 since dax can have > negative performance implications if page cache memory happens to be > faster than pmem. It should be limited to applications that > specifically want the semantic, not globally enabled for the entire > mount. xfs has went ahead and added the XFS_DIFLAG2_DAX indoe flag for > per-inode enabling of dax. Thank you so much for pointing this out. So, is there a plan to define a generic inode flag to enable dax via inode_set_flag? Or, does each filesystem need to handle it individually likewise xfs? > > I'm wondering if any new filesystem that adds dax support at this > point should do so with inode flags and not a mount option? Anyway, in such the case, I have to postpone merging this patch for a while. Thanks,
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
[ adding linux-nvdimm ] On Thu, Jul 20, 2017 at 5:10 AM, sunqiuyang wrote: > From: Qiuyang Sun > > This patch implements Direct Access (DAX) in F2FS, including: > - a mount option to choose whether to enable DAX or not We're in the process of walking back and potentially deprecating the use of the dax mount option for xfs and ext4 since dax can have negative performance implications if page cache memory happens to be faster than pmem. It should be limited to applications that specifically want the semantic, not globally enabled for the entire mount. xfs has went ahead and added the XFS_DIFLAG2_DAX indoe flag for per-inode enabling of dax. I'm wondering if any new filesystem that adds dax support at this point should do so with inode flags and not a mount option?
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
Hi Jaegeuk, Below is the error message I got from this testcase: --- write (Invalid argument) len 1024 dio [dax to nondax | both nodax] read (Bad address) len [4096 | 16777216 | 67108864] dio dax to nondax --- The write error is expected, as F2FS does not support unaligned direct IO (1024 B). The read error is more complex. In the test script, when we mmap the src file (dax), the flags (VM_MIXEDMAP | VM_HUGEPAGE) are added into vma->vm_flags. Later on, when we write to the dest file (nondax) and then read from it by direct IO, we will fail to get pages from this "special" vma. Functions involved: f2fs_direct_IO blockdev_direct_IO __blockdev_direct_IO do_direct_IO dio_get_page dio_refill_pages iov_iter_get_pages get_user_pages_unlocked __get_user_pages_fast __get_user_pages_unlocked __get_user_pages_locked __get_user_pages follow_page_mask follow_p4d_mask follow_pud_mask follow_pmd_mask follow_page_pte vm_normal_page follow_pfn_pte In my test environment HAVE_PTE_SPECIAL is true, and vm_normal_page() returns NULL due to VM_MIXEDMAP in vm_flags. Then follow_page_pte() continue to call follow_pfn_pte(), which returns -EFAULT. This is how we get a "bad address" error finally. This error also occurs in EXT4-DAX for similar reasons. Thanks, Hi Qiuyang, This fails xfstests/generic/413. Thanks, On 07/20, sunqiuyang wrote: From: Qiuyang Sun This patch implements Direct Access (DAX) in F2FS, including: - a mount option to choose whether to enable DAX or not - read/write and mmap of regular files in the DAX way - zero-out of unaligned partial blocks in the DAX way - garbage collection of DAX files, by mapping both old and new physical addresses of a data page into memory and copy data between them directly - incompatibility of DAX with inline data, atomic or volatile write, collapse|insert_range, etc. Signed-off-by: Qiuyang Sun --- Changelog v7 -> v8: - Introduce the macro f2fs_dax_file() to judge if a file is DAX for cases when CONFIG_FS_DAX is set or not - Return -ENOTSUPP when an operation does not support DAX - In f2fs_iomap_begin(), convert the inline data of an inode (if any) before mapping blocks - Minor cleanups --- Documentation/filesystems/f2fs.txt | 2 + fs/f2fs/data.c | 132 +- fs/f2fs/f2fs.h | 15 +++ fs/f2fs/file.c | 183 - fs/f2fs/gc.c | 103 - fs/f2fs/inline.c | 3 + fs/f2fs/inode.c| 8 +- fs/f2fs/namei.c| 5 + fs/f2fs/super.c| 15 +++ 9 files changed, 454 insertions(+), 12 deletions(-) diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index 273ccb2..c86c421 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -164,6 +164,8 @@ io_bits=%u Set the bit size of write IO requests. It should be set with "mode=lfs". usrquota Enable plain user disk quota accounting. grpquota Enable plain group disk quota accounting. +daxUse direct access (no page cache). See + Documentation/filesystems/dax.txt. DEBUGFS ENTRIES diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 87c1f41..4eb4b76 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -910,6 +910,15 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, err = -EIO; goto sync_out; } + /* +* If newly allocated blocks are to be zeroed out later, +* a single f2fs_map_blocks must not contain both old +* and new blocks at the same time. +*/ + if (flag == F2FS_GET_BLOCK_ZERO + && (map->m_flags & F2FS_MAP_MAPPED) + && !(map->m_flags & F2FS_MAP_NEW)) + goto sync_out; if (flag == F2FS_GET_BLOCK_PRE_AIO) { if (blkaddr == NULL_ADDR) { prealloc++; @@ -938,6 +947,8 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, blkaddr != NEW_ADDR) goto sync_out; } + } else if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) { + goto sync_out; } if (flag == F2FS_GET_BLOCK_PRE_AIO) @@ -996,6 +1007,12 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, goto next_dnode; sync_out: +
Re: [PATCH v8 1/1] f2fs: dax: implement direct access
Hi Qiuyang, This fails xfstests/generic/413. Thanks, On 07/20, sunqiuyang wrote: > From: Qiuyang Sun > > This patch implements Direct Access (DAX) in F2FS, including: > - a mount option to choose whether to enable DAX or not > - read/write and mmap of regular files in the DAX way > - zero-out of unaligned partial blocks in the DAX way > - garbage collection of DAX files, by mapping both old and new physical >addresses of a data page into memory and copy data between them directly > - incompatibility of DAX with inline data, atomic or volatile write, >collapse|insert_range, etc. > > Signed-off-by: Qiuyang Sun > --- > Changelog v7 -> v8: > - Introduce the macro f2fs_dax_file() to judge if a file is DAX for cases >when CONFIG_FS_DAX is set or not > - Return -ENOTSUPP when an operation does not support DAX > - In f2fs_iomap_begin(), convert the inline data of an inode (if any) >before mapping blocks > - Minor cleanups > --- > Documentation/filesystems/f2fs.txt | 2 + > fs/f2fs/data.c | 132 +- > fs/f2fs/f2fs.h | 15 +++ > fs/f2fs/file.c | 183 > - > fs/f2fs/gc.c | 103 - > fs/f2fs/inline.c | 3 + > fs/f2fs/inode.c| 8 +- > fs/f2fs/namei.c| 5 + > fs/f2fs/super.c| 15 +++ > 9 files changed, 454 insertions(+), 12 deletions(-) > > diff --git a/Documentation/filesystems/f2fs.txt > b/Documentation/filesystems/f2fs.txt > index 273ccb2..c86c421 100644 > --- a/Documentation/filesystems/f2fs.txt > +++ b/Documentation/filesystems/f2fs.txt > @@ -164,6 +164,8 @@ io_bits=%u Set the bit size of write IO > requests. It should be set > with "mode=lfs". > usrquota Enable plain user disk quota accounting. > grpquota Enable plain group disk quota accounting. > +daxUse direct access (no page cache). See > + Documentation/filesystems/dax.txt. > > > > DEBUGFS ENTRIES > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 87c1f41..4eb4b76 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -910,6 +910,15 @@ int f2fs_map_blocks(struct inode *inode, struct > f2fs_map_blocks *map, > err = -EIO; > goto sync_out; > } > + /* > + * If newly allocated blocks are to be zeroed out later, > + * a single f2fs_map_blocks must not contain both old > + * and new blocks at the same time. > + */ > + if (flag == F2FS_GET_BLOCK_ZERO > + && (map->m_flags & F2FS_MAP_MAPPED) > + && !(map->m_flags & F2FS_MAP_NEW)) > + goto sync_out; > if (flag == F2FS_GET_BLOCK_PRE_AIO) { > if (blkaddr == NULL_ADDR) { > prealloc++; > @@ -938,6 +947,8 @@ int f2fs_map_blocks(struct inode *inode, struct > f2fs_map_blocks *map, > blkaddr != NEW_ADDR) > goto sync_out; > } > + } else if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) { > + goto sync_out; > } > > if (flag == F2FS_GET_BLOCK_PRE_AIO) > @@ -996,6 +1007,12 @@ int f2fs_map_blocks(struct inode *inode, struct > f2fs_map_blocks *map, > goto next_dnode; > > sync_out: > + if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) { > + clean_bdev_aliases(inode->i_sb->s_bdev, > + map->m_pblk, map->m_len); > + err = sb_issue_zeroout(inode->i_sb, map->m_pblk, > + map->m_len, GFP_NOFS); > + } > f2fs_put_dnode(&dn); > unlock_out: > if (create) { > @@ -1808,16 +1825,19 @@ static int f2fs_write_data_pages(struct address_space > *mapping, > return 0; > } > > -static void f2fs_write_failed(struct address_space *mapping, loff_t to) > +static void f2fs_write_failed(struct address_space *mapping, loff_t to, > + bool lock) > { > struct inode *inode = mapping->host; > loff_t i_size = i_size_read(inode); > > if (to > i_size) { > - down_write(&F2FS_I(inode)->i_mmap_sem); > + if (lock) > + down_write(&F2FS_I(inode)->i_mmap_sem); > truncate_pagecache(inode, i_size); > truncate_blocks(inode, i_size, true); > - up_write(&F2FS_I(inode)->i_mmap_sem); > +
[PATCH v8 1/1] f2fs: dax: implement direct access
From: Qiuyang Sun This patch implements Direct Access (DAX) in F2FS, including: - a mount option to choose whether to enable DAX or not - read/write and mmap of regular files in the DAX way - zero-out of unaligned partial blocks in the DAX way - garbage collection of DAX files, by mapping both old and new physical addresses of a data page into memory and copy data between them directly - incompatibility of DAX with inline data, atomic or volatile write, collapse|insert_range, etc. Signed-off-by: Qiuyang Sun --- Changelog v7 -> v8: - Introduce the macro f2fs_dax_file() to judge if a file is DAX for cases when CONFIG_FS_DAX is set or not - Return -ENOTSUPP when an operation does not support DAX - In f2fs_iomap_begin(), convert the inline data of an inode (if any) before mapping blocks - Minor cleanups --- Documentation/filesystems/f2fs.txt | 2 + fs/f2fs/data.c | 132 +- fs/f2fs/f2fs.h | 15 +++ fs/f2fs/file.c | 183 - fs/f2fs/gc.c | 103 - fs/f2fs/inline.c | 3 + fs/f2fs/inode.c| 8 +- fs/f2fs/namei.c| 5 + fs/f2fs/super.c| 15 +++ 9 files changed, 454 insertions(+), 12 deletions(-) diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index 273ccb2..c86c421 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -164,6 +164,8 @@ io_bits=%u Set the bit size of write IO requests. It should be set with "mode=lfs". usrquota Enable plain user disk quota accounting. grpquota Enable plain group disk quota accounting. +daxUse direct access (no page cache). See + Documentation/filesystems/dax.txt. DEBUGFS ENTRIES diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 87c1f41..4eb4b76 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -910,6 +910,15 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, err = -EIO; goto sync_out; } + /* +* If newly allocated blocks are to be zeroed out later, +* a single f2fs_map_blocks must not contain both old +* and new blocks at the same time. +*/ + if (flag == F2FS_GET_BLOCK_ZERO + && (map->m_flags & F2FS_MAP_MAPPED) + && !(map->m_flags & F2FS_MAP_NEW)) + goto sync_out; if (flag == F2FS_GET_BLOCK_PRE_AIO) { if (blkaddr == NULL_ADDR) { prealloc++; @@ -938,6 +947,8 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, blkaddr != NEW_ADDR) goto sync_out; } + } else if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) { + goto sync_out; } if (flag == F2FS_GET_BLOCK_PRE_AIO) @@ -996,6 +1007,12 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, goto next_dnode; sync_out: + if (flag == F2FS_GET_BLOCK_ZERO && map->m_flags & F2FS_MAP_NEW) { + clean_bdev_aliases(inode->i_sb->s_bdev, + map->m_pblk, map->m_len); + err = sb_issue_zeroout(inode->i_sb, map->m_pblk, + map->m_len, GFP_NOFS); + } f2fs_put_dnode(&dn); unlock_out: if (create) { @@ -1808,16 +1825,19 @@ static int f2fs_write_data_pages(struct address_space *mapping, return 0; } -static void f2fs_write_failed(struct address_space *mapping, loff_t to) +static void f2fs_write_failed(struct address_space *mapping, loff_t to, + bool lock) { struct inode *inode = mapping->host; loff_t i_size = i_size_read(inode); if (to > i_size) { - down_write(&F2FS_I(inode)->i_mmap_sem); + if (lock) + down_write(&F2FS_I(inode)->i_mmap_sem); truncate_pagecache(inode, i_size); truncate_blocks(inode, i_size, true); - up_write(&F2FS_I(inode)->i_mmap_sem); + if (lock) + up_write(&F2FS_I(inode)->i_mmap_sem); } } @@ -2000,7 +2020,7 @@ static int f2fs_write_begin(struct file *file, struct address_space *mapping, fail: f2fs_put_page