On Mon, Feb 26, 2018 at 4:10 AM, zhangyi (F) <yi.zhang@xxxxxxxxxx> wrote: > On 2018/2/25 2:46, Amir Goldstein wrote: >> On Sat, Feb 24, 2018 at 11:36 AM, yangerkun <yangerkun@xxxxxxxxxx> wrote: [...] >>>> I suggest at least the following safely checks on start of fsck.overlay: >>>> - Check if index dir exists in workdir >>>> - Check if upperdir root has an unrecognized origin xattr format >>>> - Check if index dir root has an unrecognized origin xattr format >>>> >>>> If any of the checks above is positive, fsck.overlay should issue a >>>> warning >>>> and refuse to fix fielsystem. Running with -n -f is allowed. >>>> See if index dir exists, then removing origin xattr can corrupt the index. >>>> When fsck.overlay gains the knowledge about checking and fixing index, >>>> user would opt-in to checking an overlayfs with index by -o index=on >>> >>> >>> When compile the kernel, we can choose the default config about overlay, >>> which user won't get. So, user may choose the fault arguments like >>> "fsck.overlay -olower..." while index xattr is on when there is really >>> overlayfs. Other filesystems can get xattr from superblock in disk, but we >>> cannot use this way in overlay. So, how to deal with this？ >>> >>> >> >> The kernel default options for overlayfs mount really does not matter for >> fsck.overlay. The only thing that matters is to detect whether the layers >> were *ever* mounted by a kernel which enabled features that fsck.overlay >> does not support. >> >> The current state of fsck.overlay is: >> - supports redirect feature >> - does not support any other feature including upstream features index and >> nfs_export and future features like metacopy. >> >> A filesystem repair tool should NOT fix the filesystem if it detects on-disk >> format that it does not recognize. >> >> That means among other things for overlayfs that if an xattr if found on any >> file by the name of trusted.overlay.<something> and <something> is not a >> an expected name, then fsck.overlay should shout that it does not >> recognize the on-disk format (print out the unrecognized xattr name) and >> refuse to continue. >> >> The problem with overlayfs compares to traditional filesystems is the lack >> of "feature bits" in the "super block", so there is no O(1) test for unsupported >> features, but they still can be detected. >> >> Contrary to the example above, there is a simple O(1) test to check if >> overlayfs was mounted with index feature enabled - the existence of a >> non empty $workdir/index dir is de-facto a "feature bit" and until fsck.overlay >> knows how to verify and fix overlayfs without corrupting the index it should >> refuse to fix an overlay filesystem with an index. >> > > Maybe we can store "feature bit" in upper root xattr or somewhere else in workdir > after we implement mkfs.overlay, and classify them into compat and incompat > features, we can use old fsck.overlay to fix the filesystem if there is no > unrecognized incompat feature. > Yes, we could and probably should. A "feature set" as xattr was proposed by Miklos when introducing redirect_dir [1]. and then I proposed a different implementation of "feature set" when introducing index feature [2]. The biggest problem with these implementation is that old kernel doesn't know about the incompat features. For this problem, fsck.overlay is at least a partial solution, because it will be possible for user to run fsck.overlay to "sanitize" an overlayfs for mount with old kernel, for example: fsck.overlay -o redirect_dir=off,index=off (*) could be used to sanitize overlayfs for mount on kernel < v4.10. (*) Another option is to follow mkfs.ext4/tune2fs standard of -O ^redirect_dir,^index. IMO, now that fsck.overlayfs has materialized, thanks to you, it is a good time to set the feature set format in stone and implement it in kernel and fsck (hint hint, if you post I will review...) > Before this, the index dir can be treated as a kind of "unrecognized incompat > feature", so the "simple O(1) test" can works well, but how can we handle > another incompat feature tomorrow? Should we implement mkfs.overlay before the > first release version of fsck.overlay? > I wouldn't say that we need to implement mkfs.overlay, but we *do* need to define the feature set on-disk format and fsck.overlay *does* have to check the incomapt features from the very first release and new kernel *should* check and set the "feature bits". I am in favor of something similar to [1], but with 3 sets of features: compat,incompat,rocompat. If I am not missing anything, upstream overlayfs now supports 4 on-disk format features that were not supported in the first upstream release (v3.18): incomapt: redirect_dir rocompat: index,nfs_export compat: constant_ino (i.e. origin+impure xattr) redirect_dir can be detected only by scanning all dirs. constant_ino can be detected only by scanning all files. It's not really that important to cleanup a compat feature that the first version of fsck supports, but its not hard to implement it either. index can be detected by checking index dir exists (or not empty). nfs_export can be detected by checking if index dir contains whiteout and directory entries. IMO we should not merge another incompat feature like metacopy before defining the feature set format and setting the incompat "feature bit" on first mount with metacopy enabled. Thanks, Amir. [1] https://marc.info/?l=linux-unionfs&m=147739471816673&w=2 [2] https://marc.info/?l=linux-unionfs&m=150885903123037&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
