linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>,
	linux-ext4@vger.kernel.org, sfrench@samba.org,
	darrick.wong@oracle.com, jlayton@kernel.org,
	bfields@fieldses.org, paulus@samba.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC v6 00/11] Ext4 Encoding and Case-insensitive support
Date: Fri, 22 Mar 2019 19:57:08 -0400	[thread overview]
Message-ID: <20190322235708.GA5675@mit.edu> (raw)
In-Reply-To: <05dfd6a7-49f0-81a7-cd68-ff9f07182461@infradead.org>

On Thu, Mar 21, 2019 at 03:30:35PM -0700, Randy Dunlap wrote:
> I briefly scanned but did not look terribly closely:
> 
> Does this patch series ignore ext3 filesystems that are being handled
> by the ext4fs code?

Like all ext2/3/4 features, new functionality is gated by a feature
bit in the compat, rocompat, or incompat bitmasks.  A file system
implementation (e.g., in the Linux kernel, NetBSD/FreeBSD, Grub,
et. al) which sees a feature bit it doesn't recognize in an rocompat
bitmask will only allow the file system to be mounted read-only.  If
it sees a bit in the incompat bitmask it doesn't recognize, it won't
allow the file system to be mounted at all.  The kernel doesn't care
if it finds a bit it doesn't recognize in the compat bitmask; however,
e2fsck will not touch a file system that has a compat bit which it
doesn't know how to deal with.

Strictly speaking, there is no such thing as an "ext3 file system".
There are just file systems with a set of feature bits set.  And the
set of features supported by NetBSD or the Grub installer may not fall
neatly into the "ext2", "ext3", or "ext4" buckets. 

If by "ext3 file system" you mean a file system with those featire
bits set by mke2fs -t ext3 by default (e.g., not overridden by the -O
option, or by the system administrator editing /etc/mke2fs.conf), then
yes, this patch series will not result in any substantive change for
"ext3 file systems", since it by default "mke2fs -t ext3" or
"mkfs.ext3" will not enable the feature flag that turns on
case-insensitive support.

For more information, see the ext4 and mke2fs.conf manual pages.

Cheers,

					- Ted


      reply	other threads:[~2019-03-23  0:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-18 20:27 [PATCH RFC v6 00/11] Ext4 Encoding and Case-insensitive support Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 01/11] unicode: Add unicode character database files Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 02/11] scripts: add trie generator for UTF-8 Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 03/11] unicode: Introduce code for UTF-8 normalization Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 04/11] unicode: reduce the size of utf8data[] Gabriel Krisman Bertazi
2019-04-06 19:53   ` Theodore Ts'o
2019-04-08 12:02     ` Weber, Olaf (HPC Data Management & Storage)
2019-03-18 20:27 ` [PATCH RFC v6 05/11] unicode: Implement higher level API for string handling Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 06/11] unicode: Introduce test module for normalized utf8 implementation Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 07/11] MAINTAINERS: Add Unicode subsystem entry Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 08/11] ext4: Include encoding information in the superblock Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 09/11] ext4: Support encoding-aware file name lookups Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 10/11] ext4: Implement EXT4_CASEFOLD_FL flag Gabriel Krisman Bertazi
2019-03-18 20:27 ` [PATCH RFC v6 11/11] docs: ext4.rst: Document encoding and case-insensitive Gabriel Krisman Bertazi
2019-03-21 22:30 ` [PATCH RFC v6 00/11] Ext4 Encoding and Case-insensitive support Randy Dunlap
2019-03-22 23:57   ` Theodore Ts'o [this message]

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=20190322235708.GA5675@mit.edu \
    --to=tytso@mit.edu \
    --cc=bfields@fieldses.org \
    --cc=darrick.wong@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=krisman@collabora.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=rdunlap@infradead.org \
    --cc=sfrench@samba.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).