On Wed 04-08-21 15:04:10, Theodore Ts'o wrote: > On Mon, Jul 12, 2021 at 05:43:14PM +0200, Jan Kara wrote: > > Enable orphan_file feature by default in larger filesystems. Since the > > feature is COMPAT, older kernels will just ignore it and happily work > > with the filesystem as well. > > > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > We'll need to decide whether we want to enable this by default, at > least initially. The general practice has been to not enable new > kernel functionality right away by default. It's true that older > kernels will ignore the feature if they aren't orphan_file aware; > however, we if have a file system which is created with orphan_file > eanbled, but that file system with the orphan_file feature is made > available to a system which is running an orphan_file-aware kernel, > but the distro hadn't picked up the a version e2fsprogs which is > orphan_file-aware. This might happen if the file system was created > on one system, and then it gets connected to an system w/o a new > version of e2fsprogs (e.g. via fibre channel, iscsi, AWS EBS, GCE PD, > etc), then could be a surprise to the user. So that's something for > us to discuss. Yes, I think you are right that enabling the functionality by default right from the start may be too aggressive. I'm fine with postponing this for some time. > In the shorter term, there's another problem I've notied, which is if > we add this to mke2fs.conf, and the user runs: > > mke2fs -t ext4 -O ^has_journal foo.img 1G > > mke2fs will fail mid-way through the mkfs process with the error > message, "mke2fs: cannot set orphan_file flag without a journal". > This represents a regression, and if we don't want to drop orphan_file > from the default feature set in mke2fs.conf, I think we'll need to > check for the case where the file system doesn't have a journal, and > only fail when the user has explicitly requested orphan_file on the > command line. But if orphan_file is a default as defined in > mke2fs.conf, and the journal is not present for whatever reaseon, we > need to silently disable the orphan_file feature. Good catch. I'll fix this. > (Also note that to avoid user confusion, we should refer to > orphan_file as a "feature" instead of a "flag". Even for things like > "orphan_present" or "recovery_needed" it is probably clearer to call > them features, simply because it makes it easier for system > adminsitrators and developers to be able to find the "flag" location.) Good point. I've fixed up couple of occurences of 'flag' I've found in the messages. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR