Lustre devel - Jan 2007 - [Bug 10933] POSIX Test Suite results: Lustre vs. ext3 differences.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10933



The latest download versions of the suite from the Open Group
(lts_vsx-pcts2.0beta2.tgz, tet_vsxgen_3.02.tgz) have been modified so that a
custom kernel (with NGROUPS_MAX = 32) is not needed to run the test suite.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10933



Several of the tests of fcntl will fail if the file system is not mounted with
the flock option.  Subsequent discussion of the test results assume Lustre is
mounted with the flock option, although that is not our practice in the computer
center.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10933



Created an attachment (id=9410)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9410&action=view)
latest report comparing 3 relevant POSIX test runs

The attached report is a comparison of the CFS provided ext3_baseline, A run of

the test suite on a cleanly installed Lustre, and a run of the suite after many

repeats.  There are additional failures that come in after some runs.  The only

way I have found to reestablish the "clean" runs is to make a freash
installation of Lustre and of the test suite.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10933



Created an attachment (id=9411)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9411&action=view)
Descriptions of failing tests from the POSIX suite

The attached report includes the descriptions of all tests that eventually fail

when running the POSIX test suite.  This include all of the failures from a
"clean" run, and all of the additional failures that eventually occur
when many

iterations have been performed.

Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10933



(From update of attachment 9411)
>	************************************************************************
>	/tset/POSIX.os/files/access/T.access 43	Unresolved
>	
>		Test Description:
>	If the implementation supports a read-only file system, EROFS in errno
>	and a return value of -1 on a call to access(path, amode) when write
>	access is requested for a file on a read-only file system.
>	Posix Ref: Component ACCESS Assertion 5.6.3.4-48(C)
The EROFS fail because the POSIX test suite doesn''t know how to remount
the
Lustre filesystem read-only.  It might work on the first test because it
(AFAIR) installs an ext2 loopback filesystem to mount read-only, and subsequent
tests don''t have the loop device set up correctly.

It _might_ be possible to handle this with a zconf-mounted client where you
specify the "device" as {mdsnode}:/{mdsname}/client but I''m
not sure...
>	************************************************************************
>	/tset/POSIX.os/files/fpathconf/T.fpathconf 3	Unresolved
>	
>		Test Description:
>	For the XNFS specification:
>	    Not in use.
>	For the XSH specification:
>	    A call to fpathconf(fildes, _PC_MAX_CANON) when fildes refers to a
>	    terminal file, returns a value >= {_POSIX_MAX_CANON} or returns -1
>	    without setting errno.
>	Posix Ref: Component FPATHCONF Assertion 5.7.1.2-06(A)
>	
>		Test Information:
>	open("/dev/pts/1", O_RDONLY|O_NONBLOCK) failed - errno 2 (ENOENT)
>
>	************************************************************************
This doesn''t appear to be Lustre related.
>	************************************************************************
>	/tset/POSIX.os/files/link/T.link 15	Failed
>	
>		Test Description:
>	If {_POSIX_LINK_MAX} F {LINK_MAX} F {PCTS_LINK_MAX}, then EMLINK in
>	errno and a return value of -1 on a call to link(path1, path2) when
>	{LINK_MAX} links to the file named by the argument path1 already
>	exist;
>	                              otherwise
>	{PCTS_LINK_MAX} links can be created to the file specified by argument
>	path1.
>	Note: For XNFS testing, the value for {LINK_MAX} is determined on the
>	server.
>>
>	Posix Ref: Component LINK Assertion 5.3.4.4-49(A)
>	
>		Test Strategy:
>	ERRNO VALUES: expected: 31 (EMLINK), observed: 0 (NO ERROR)
>
>	************************************************************************
The EMLINK failures are because Lustre doesn''t have a max link
subdirectory
link bugz 11510count on directories, unlike ext3 (see bug 2727).
>	************************************************************************
>	/tset/POSIX.os/files/mkdir/T.mkdir 19	Unresolved
>	
>		Test Description:
>	ENOSPC in errno and a return value of -1 on a call to mkdir(path,
>	mode) when the file system does not contain enough space to hold the
>	contents of the new directory or to extend the parent directory of the
>	new directory.
>	Posix Ref: Component MKDIR Assertion 5.4.1.4-38(B)
>	
>		Test Information:
>	creat failed in setupnospc
>
>	************************************************************************
This is likely a POSIX harness failure, likely because the test filesystem is
too large?
>	************************************************************************
>	/tset/POSIX.os/files/rmdir/T.rmdir 4	Failed
>	
>		Test Description:
>	For the XNFS specification:
>	    Not in use.
>	For the XSH specification:
>	    When a process has the directory open when the last link is
>	    removed, then when rmdir() returns there shall not be a dot and
>	    dot-dot entry and no new entries may be created in the directory.
>	Posix Ref: Component RMDIR Assertion 5.5.2.2-27(A)
>	
>		Test Strategy:
>	CREATE directory using crdir()
>	OPEN directory using opendir()
>	REMOVE directory using rmdir()
>	VERIFY that rmdir() returned 0
>	VERIFY that the directory no longer exists using eaccess()
>	SET file pointer to start of directory using rewinddir()
>	READ all directory entries using readdir()
>	VERIFY that entries for "." and ".." are not found
>	CREATE file using crfile() - (genlib) within deleted directory
>	VERIFY that file is not created
>	CLOSE directory using closedir()
>	
>		Test Information:
>	open directory contained entry "." after
rmdir("rmdir-d.4")
>	open directory contained entry ".." after
rmdir("rmdir-d.4")
>
>	************************************************************************
This is a known problem (bug 2193), but not considered harmful.