From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Pavel Reichl <preichl@redhat.com>,
fstests@vger.kernel.org, shreeya.patel@collabora.com
Subject: Re: [PATCH 1/1] generic/453: Do NOT run for FSs restricting names
Date: Wed, 7 Jul 2021 18:40:05 -0400 [thread overview]
Message-ID: <YOYtRXrc5EdOqcHp@mit.edu> (raw)
In-Reply-To: <20210707145158.GC11571@locust>
On Wed, Jul 07, 2021 at 07:51:58AM -0700, Darrick J. Wong wrote:
> # Skip this test unless the filesystem treats names (directory entries,
> # fs labels, and extended attribute names) as raw byte sequences.
>
> > + case "$FSTYP" in
> > + ext2|ext3|ext4|xfs|btrfs)
>
> Does this need to _notrun ext4 filesystems that have casefolding
> enabled? (Or: should we let the ext4 developers figure that out?)
Casefolding has to be enabled on the file system level (mkfs.ext4 -O
casefold) but also on a per-directory level (by setting the casefold
flag). Otherwise, unrestricted byte streams are allowed for file
names. Since generic/453 doesn't set the casefold flag, this tests
passes even when the scratch mount options include casefolding.
The generic/556 test will test casefolding.
BTW, we should probably include f2fs as a file system which normally
allow unrestricted byte streams. F2fs also supports casefolding, but
again, like ext4, it's only enabled when the per-directory casefold
flag is enabled. So:
+ case "$FSTYP" in
+ ext2|ext3|ext4|f2fs|xfs|btrfs)
I've verified that generic/453 passes on f2fs today.
- Ted
next prev parent reply other threads:[~2021-07-07 22:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 10:20 [PATCH 0/1]: generic/453: Do NOT run for FSs restricting names Pavel Reichl
2021-07-07 10:20 ` [PATCH 1/1] " Pavel Reichl
2021-07-07 14:51 ` Darrick J. Wong
2021-07-07 22:40 ` Theodore Ts'o [this message]
2021-07-08 6:16 ` Pavel Reichl
2021-07-07 17:34 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YOYtRXrc5EdOqcHp@mit.edu \
--to=tytso@mit.edu \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=preichl@redhat.com \
--cc=shreeya.patel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.