On Thu, Dec 01, 2016 at 06:42:00PM +0200, Amir Goldstein wrote: > On Tue, Nov 29, 2016 at 1:37 PM, Eryu Guan <eguan@xxxxxxxxxx> wrote: > > On Tue, Nov 29, 2016 at 10:53:36AM +0200, Amir Goldstein wrote: > > >> > >> Eryu and all, > >> > >> I wanted to ask what is the common practice for introducing tests for > >> know issues > >> that are *about* to be solved. > >> > >> What is the preferred timing for merging these sort of tests? > >> Is it productive to have these tests merged before a fix is merged to master? > >> Before a fix is queued for next? > >> Before a fix is available? > > > > Basically new regression tests will be merged as soon as possible, as > > long as there're no objections from reviewers or all comments are > > addressed. > > > > One exception is that for tests that could crash latest maintainer's > > tree (even there's a known fix), I'd perfer letting the fix go upstream > > first, so that the test doesn't break anyone's tests by crashing all the > > testing hosts. It's great if the test author could give a notification > > on the test to say that the fix has been merged, so the test could be > > merged too. I'll watch the patch status too, but maybe not so timely. > > > > Nothing of a sort lurking with the tests I am planning to write. > Just tests that check for "Non-standard behavior" of overlayfs, > some of it described in Documentation/filesystems/overlayfs.txt. > > > > >> > >> FYI, the fix for the test in this patch (test ro/rw fd data inconsistencies) > >> is not queued for next yet, but I am hoping it will be. > >> Miklos? > > > > FYI, this test is already in my last pull request to Dave. > > > > Eryu, > > I am getting this error when running my test with an older xfs_io (4.3.0). > I generated the good output with xfs_io from Dave's for-next branch (4.8.0). > > Have you any idea why in one setup I see the commands echoed > to output and not in the other? I think there's a bug somewhere in xfs_io to do with command line repetition of the open command. That is: # xfs_io xfs_io> open foo xfs_io> open -r foo xfs_io> print 000 foo (foreign,non-sync,non-direct,read-write) [001] foo (foreign,non-sync,non-direct,read-only) xfs_io> Shows we have two open files, the second being read only. Fromteh command line, opening a read-only file: # xfs_io -r -c file foo [000] foo (foreign,non-sync,non-direct,read-only) # But if we try to open a second file from the CLI: sudo xfs_io -r -c "open -f bar" -c print foo bar: Too many open files [000] foo (foreign,non-sync,non-direct,read-only) 001 bar (foreign,non-sync,non-direct,read-write) 002 bar (foreign,non-sync,non-direct,read-write) 003 bar (foreign,non-sync,non-direct,read-write) 004 bar (foreign,non-sync,non-direct,read-write) 005 bar (foreign,non-sync,non-direct,read-write) 006 bar (foreign,non-sync,non-direct,read-write) ..... It just falls into an endless loop opening the file until we run out fd space. Oh, there's bugs all over the place here - Ok, I think the command loop handling is broken - it's making my head hurt right now. Functions that don't set CMD_FLAG_GLOBAL have problems with not breaking out of the args processing loop. I'll deal with this on Monday, not at beer o'clock on Friday afternoon. > I realize that the use of redirecting commands from here document > to xfs_io has not been used in xfstests before, but I could not find > another way to use 'open' commands, which are needed for this test. Let's fix xfs_io rather than hack yet another whacky way to execute xfs_io into xfstests... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
