On 2017/11/20 15:29, Amir Goldstein Wrote: > On Mon, Nov 20, 2017 at 8:56 AM, zhangyi (F) <yi.zhang@xxxxxxxxxx> wrote: >> On 2017/11/18 1:13, Amir Goldstein Wrote: > [...] >> >>>> >>>> This patch can am to an empty git repository. I have already do basic >>>> test list in 'test' directory. Please do a review give some suggestions. >>>> Thanks a lot. >>> >>> Please consider, instead of writing overlay tests in new repo, >>> to write the tests for xfstests and hook overlay.fsck to _check_test_fs/ >>> _check_scratch_fs. >>> See for example very basic index sanity checks I implemented here: >>> https://github.com/amir73il/xfstests/commit/dac4da479e3e85be8f7beec54f384c0a832f74bd >>> >> >> I found that e2fsprogs put tests in the e2fsprogs repository, so I write it >> and put in the same place. Now I notice that all xfs test cases put together >> in xfstests, so It's also a good choice, not sure which one is better. How >> about Eryu's opinion ? >> > > Looks. It's not a terrible idea to have some amount of duplication with tests > and it's fine you with to keep some independent test within the progs repositiry > as a "self test". But you will benefit a lot more testers on more machines and > configurations if you merge all the interesting overlay tests to "fstests" repo, > which a lot more people are running. > And yes, there are quite a lot of tests in xfstest to verify correctness of > xfs_repair. Self testing the main fs sanity check program is a good idea. > > >>> It may be useful, if Eryu agrees, to merge the "incubator" version of >>> fsck.overlayfs >>> into xfstests as a helper program until it starts getting packaged and >>> distributed. >>> Please consider this option. >>> >> >> Can we applay for a repository in git.kernel.org like xfsprogs-dev and e2fsprogs ? > > "Kernel.org accounts are not given away very often, usually you need > to be making some > reasonable amount of contributions to the Linux kernel and have a good > reason for wanting > / needing an account" > > It doesn't hurt to ask, but I suspect an incubation period for > fsck.overlay in another location > before it gets enough traction might be a good idea. > You may ask Miklos to maintain overlayfs-progs on kernel.org getting > patches from you, > but I guess this was not your intention. > > [...] > >>>> +Redirect directories >>>> +-------------------- >>>> + >>>> +An redirect directory is a directory with "trusted.overlay.redirect" xattr >>>> +valued to the path of the original location from the root of the overlay. It >>>> +is only used when renaming a directory and "redirect dir" feature is enabled. >>>> +If an redirect directory is found, the following must be met: >>>> + >>>> +1) The directory store in redirect xattr should exist in one of lower layers. >>>> +2) The origin directory should be redirected only once in one layer, which mean >>>> + there is only one redirect xattr point to this origin directory in the >>>> + specified layer. >>>> +3) A whiteout or an opaque directory with the same name to origin should exist >>>> + in the same directory as the redirect directory. >>> another redirected upper dir can also be covering the redirect lower target >>> >> Do you mean the following case: upper's dir_rd cover lower1's redirect dir_rd ? >> >> Upper: dir_rd(redurected,opaque) dir2(whiteout) >> Lower1: dir(whiteout) dir_rd(redurected) dir2 >> Lower0: dir >> > > That's not what I meant. What I meant is: > > Upper: A (whiteout), B (redirect=A), C (redirect=B) > Lower: A (dir), B (dir) > > The redirect target of upper C (B) is not a whiteout in upper, nor an > opaque dir. > It is a redirected dir (whose own target is covered by a whitetout A). > The description in 3) doesn't cover that case. Didn't check how the program > handles this case. > Indeed, I missed this situation, will add. Thanks, Yi. -- 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
