Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2876806yba; Mon, 6 May 2019 13:04:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxN52kl0gZg51m16f36VKxrYinS4vw6ACmAJiSv6mglc2Cu+5KYyk5npvSfz//SuvVqk+nM X-Received: by 2002:a17:902:6a89:: with SMTP id n9mr35338033plk.76.1557173042032; Mon, 06 May 2019 13:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557173042; cv=none; d=google.com; s=arc-20160816; b=bN9pHvNCZOtZAAlazEBNsdJm282JrQNStwKEIcUmfXkQpk0yNk1YusiEWvz/q5Euzh Rc8xbpR53RX4nkTNptDl0DESEK65mSHt2gaouTXNszyuhJVYm0+2QmeK86HoqKOvSj88 WI2Q3IlkJRIgPVyA9T/EOEL6NY40xaqMNX0LETupYR043E8eJTGKgMO3AOw1/avX91Qj lc/QP4XR4x+W+KM02+/kJyrZiRDB68RHcXZMtOKM5mPElWh3TRp2+2rMcKpknoHSSB7C Fce235PYB7Pm7S/4KAyD8jvHRYJLpZu1GraemUnL0DrSBHhyZF05aD8OrVyul+jo7Wo7 7ThA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=frNBJU4H8ZCVnGlDzzNcueCR/dt4TDgJVVhulzFLUco=; b=tmrGH7UqLorH9WxepsNT22Xy73KVUe4jUvDJ7EfGPht39O2/YyCKmJJ6uEbgX/9qcd G8Zx34ZlgNmJGNNlBJSvkBpbvWd5hOJFESHaFpN8h2PK8SJupPjsq0EpZZMJ1fwS7Uek to5+8PPWSVGvJ3VeThgyRsm8Ru5kUZFDL7w/VyHZQU4Xbb0kmIUorXb2LXfCozMiticQ r8ydRu1Bemkq/RvvrkK0poHrdxU9dhVHT+sD+DXwmiqmA8qX7BZIknUYRcjcm+llAT2v PnnEkmW35X3RZF/eij1ZgRnwzn1wIvexEbqR3G4bLDfU1QhwanN7oC/S5lkz97m8FX2z anrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 76si7914320pgf.582.2019.05.06.13.03.39; Mon, 06 May 2019 13:04:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726268AbfEFUDb (ORCPT + 99 others); Mon, 6 May 2019 16:03:31 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:56195 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726124AbfEFUDb (ORCPT ); Mon, 6 May 2019 16:03:31 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-109.corp.google.com [104.133.0.109] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x46K3Q3m002320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 16:03:27 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id F2BD9420024; Mon, 6 May 2019 16:03:25 -0400 (EDT) Date: Mon, 6 May 2019 16:03:25 -0400 From: "Theodore Ts'o" To: Gabriel Krisman Bertazi Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH xfstests 1/2] common/casefold: Add infrastructure to test filename casefold feature Message-ID: <20190506200325.GA3985@mit.edu> References: <20190506185941.10570-1-krisman@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506185941.10570-1-krisman@collabora.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, May 06, 2019 at 02:59:40PM -0400, Gabriel Krisman Bertazi wrote: > +_require_test_casefold_feature () { > + _has_casefold_feature $TEST_DEV || \ > + _notrun "Feature casefold required for this test" > +} > +_require_scratch_casefold_feature () { > + _has_casefold_feature $SCRATCH_DEV || \ > + _notrun "Feature casefold required for this test" > +} I've just pushed out a commit to ext4.git tree which will cause /sys/fs/ext4/features/casefold will exist iff CONFIG_UNICODE is present. This will allow the test to check whether or not the kernel version and configuration will support the casefold feature. Could you add a check for this flag if the file system type is ext4? A file system independent way of doing this would be to create a test file system on the test file system, calling "chattr +F" on the directory. If it fails, then either the file system doesn't support it or the chattr program is too old and doesn't support casefold. If the chattr +F succeeds, then the test should call lsattr -d on the directory and make sure the request to set casefold flag was actually honored; some file systems will simply fail to set flags that they don't support, so we do need to do a SETFLAGS followed by a GETFLAGS to be sure that it was supported. Speaking of file system independent casefold, I believe that it will be likely that the casefold feature will be supported by f2fs in the fullness of time. If that happens, how to test for the file system feature will be different (since dumpe2fs is ext4-specific), but I would expect "chattr +F" interface to be the same between ext4 and f2fs. This might mean that we should add casefold tests to either generic/ or shared/ instead of ext4/ --- I think it would be shared since at least initially it would only be ext4 and f2fs, and I haven't seen any indication than other file systems would be interested in adding casefold support. Or we can move the casefold tests later from ext4/ to shared/ once the f2fs support materializes. Cheers, - Ted