On Thu, Jan 11, 2024 at 09:05:51PM -0800, Linus Torvalds wrote:
> On Thu, 11 Jan 2024 at 10:28, Jaegeuk Kim wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
> > tags/f2fs-for-6.8-rc1
>
> Hmm. I got a somewhat confusing conflict in f2fs_rename().
>
> And honestly,
The pull request you sent on Thu, 11 Jan 2024 10:28:10 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
> tags/f2fs-for-6.8-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/70d201a40823acba23899342d62bc2644051ad2e
Thank you!
--
On Thu, 11 Jan 2024 at 10:28, Jaegeuk Kim wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
> tags/f2fs-for-6.8-rc1
Hmm. I got a somewhat confusing conflict in f2fs_rename().
And honestly, I really don't know what the right resolution is. What I
ended up with was
On 2023/12/29 11:25, Wu Bo wrote:
'f2fs_is_checkpoint_ready()' checks free sections. If there is not
enough free sections, most f2fs operations will return -ENOSPC when
checkpoint is disabled.
It would be better to check free sections before disable checkpoint.
Signed-off-by: Wu Bo
On 2024/1/12 1:15, Daeho Jeong wrote:
On Wed, Jan 10, 2024 at 5:33 PM Chao Yu wrote:
On 2024/1/11 9:18, Daeho Jeong wrote:
On Thu, Dec 28, 2023 at 6:33 AM Chao Yu wrote:
From: Sheng Yong
Compressed cluster may not be released due to we can fail in
release_compress_blocks(), fix to
Right now, we have two functions that can be called by the filesystem
during lookup to set up fscrypt internal state for the dentry and
inode under lookup:
1) fscrypt_prepare_lookup_dentry_partial: used only by ceph. It sets
encryption information in the inode and sets the dentry flag if the
No filesystems depend on it anymore, and it is generally a bad idea.
Since all dentries should have the same set of dentry operations in
case-insensitive filesystems, it should be propagated through ->s_d_op.
Signed-off-by: Gabriel Krisman Bertazi
---
fs/libfs.c | 34
In preparation to get case-insensitive dentry operations from
sb->s_d_op again, use the same structure for case-insensitive
filesystems with and without fscrypt.
This means that on a casefolded filesystem without fscrypt, we end up
having to call fscrypt_d_revalidate once per dentry, which does
Unencrypted and encrypted-dentries where the key is available don't need
to be revalidated with regards to fscrypt, since they don't go stale
from under VFS and the key cannot be removed for the encrypted case
without evicting the dentry. Mark them with d_set_always_valid, to
avoid unnecessary
This was already the case for case-insensitive before commit
bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), but it
was changed to set at lookup-time to facilitate the integration with
fscrypt. But it's a problem because dentries that don't get created
through ->lookup() won't have
This was already the case for case-insensitive before commit
bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), but it
was changed to set at lookup-time to facilitate the integration with
fscrypt. But it's a problem because dentries that don't get created
through ->lookup() won't have
fscrypt now supports configuring dentry operations at dentry-creation
time through the preset sb->s_d_op, instead of at lookup time.
Enable this in ubifs, since the lookup-time mechanism is going away.
Signed-off-by: Gabriel Krisman Bertazi
---
fs/ubifs/dir.c | 1 -
fs/ubifs/super.c | 1 +
2
Hi,
Thank you, Eric and Al, for your feedback on the previous version.
This version has some big changes: instead of only configuring on the
case-insensitive case, we do it for case-sensitive fscrypt as well, and
disable d_revalidate as needed. This pretty much reverses the way
fscrypt operated
In preparation to drop the similar helper that sets d_op at lookup time,
add a version to set the right d_op filesystem-wide, through sb->s_d_op.
The operations structures are shared across filesystems supporting
fscrypt and/or casefolding, therefore we can keep it in common libfs
code.
overlayfs relies on the filesystem setting DCACHE_OP_HASH or
DCACHE_OP_COMPARE to reject mounting over case-insensitive directories.
Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their
d_ops"), we set ->d_op through a hook in ->d_lookup, which
means the root dentry won't have them,
>From fscrypt perspective, once the key is available, the dentry will
remain valid until evicted for other reasons, since keyed dentries don't
require revalidation and, if the key is removed, the dentry is
forcefully evicted. Therefore, we don't need to keep revalidating them
repeatedly.
Hi Linus,
Happy new year!
Could you please consider this pull request?
Thank you.
The following changes since commit 6bc40e44f1ddef16a787f3501b97f1fff909177c:
Merge tag 'ovl-fixes-6.7-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs (2023-11-17
09:18:48 -0500)
are
On Wed, Jan 10, 2024 at 5:26 PM Chao Yu wrote:
>
> On 2024/1/11 8:55, Daeho Jeong wrote:
> > On Thu, Dec 28, 2023 at 6:33 AM Chao Yu wrote:
> >>
> >> If data block in compressed cluster is not persisted with metadata
> >> during checkpoint, after SPOR, the data may be corrupted, let's
> >>
On Wed, Jan 10, 2024 at 5:33 PM Chao Yu wrote:
>
> On 2024/1/11 9:18, Daeho Jeong wrote:
> > On Thu, Dec 28, 2023 at 6:33 AM Chao Yu wrote:
> >>
> >> From: Sheng Yong
> >>
> >> Compressed cluster may not be released due to we can fail in
> >> release_compress_blocks(), fix to handle reserved
We may trigger high frequent checkpoint for below case:
1. mkdir /mnt/dir1; set dir1 encrypted
2. touch /mnt/file1; fsync /mnt/file1
3. mkdir /mnt/dir2; set dir2 encrypted
4. touch /mnt/file2; fsync /mnt/file2
...
Although, newly created dir and file are not related, due to
commit bbf156f7afa7
20 matches
Mail list logo
