Hi extX developers,
This is a resend as a consequence of the ext3 home page at
http://ext2.sourceforge.net/ referring to
http://fedoraproject.org/wiki/ext3-devel which is referring to
[email protected] which asked me to resend here.
---------- Forwarded message ----------
Date: Thu, 3 Apr 2008 00:29:47 +0300 (EEST)
From: Szabolcs Szakacsits <[email protected]>
Cc: [email protected], [email protected],
[email protected], [email protected],
Marc Andre Tanner <[email protected]>,
Jean-Pierre ANDRE <[email protected]>
To: [email protected]
Subject: [ANNOUNCEMENT] Linux POSIX file system test suite
Hello file system developers,
There are several POSIX file system test suites: closed source, commercial,
one which needs reading 174 pages installation guide, etc. Because of these
frustrations when Pawel Jakub Dawidek ported ZFS to FreeBSD, he also wrote
such a test suite quickly.
Last year the NTFS-3G team ported it to Linux/ext3 and Linux/NTFS-3G to
validate Jean-Pierre Andre's full file permissions and ownership support
for NTFS-3G. We sent our patches to Pawel for integration but this doesn't
seem to happen him (he didn't see problems but is busy).
Since this topic regularly appears on several lists, we are also often
asked about it and NTFS-3G does need it to be maintained, hence we decided
to release it and if nobody else would like to maintain it then we will do
so.
The test suite mostly checks POSIX compliance and works for FreeBSD,
Solaris, and Linux with UFS, ZFS, ext3, and NTFS-3G file systems. The list
of system calls tested is: chmod, chown, link, mkdir, mkfifo, open, rename,
rmdir, symlink, truncate, unlink. There are currently 1950 regression
tests.
Availability:
http://ntfs3g.org/sw/qa/pjd-fstest-20080402.tgz
and in the NTFS-3G CVS as pjd-fstest module:
http://sourceforge.net/cvs/?group_id=181143
The usage is extremely simple:
# tar czf pjd-fstest-20080402.tgz
# cd pjd-fstest-20080402
# vi tests/conf
Change 'fs' to file system type you want to test (UFS, ZFS, ext3, ntfs-3g).
# make
It will compile fstest utility which is used by regression tests.
# cd /path/to/file/system/you/want/to/test/
The test must be run as root user and requires a few basic Perl modules.
# prove -r /path/to/fstest/
It's also possible to run individual set of tests:
# /path/to/fstest/tests/chown/00.t
Or make single system call tests:
# fstest mkdir foo 0750
0
# fstest mkdir foo 0750
mkdir returned -1
EEXIST
The test suite is easy to understand, modify and extend. For instance doing
a test cases for the above examples is only
expect 0 fstest mkdir foo 0750
expect EEXIST fstest mkdir foo 0750
The default file system type is ext3 and it passes all tests.
NTFS-3G also passes all the tests if the latest PERMISSION_HANDLING_BRANCH
CVS branch is used with the below UserMapping file placed in the .NTFS-3G
control directory:
--------------------------------------------------------------->
:500:S-1-5-21-2271520284-214583110-2989893066-513
500::S-1-5-21-2271520284-214583110-2989893066-1007
# default mapping pattern
::S-1-5-21-2271520284-214583110-2989893066-10000
<--------------------------------------------------------------
Many thanks to Pawel Jakub Dawidek for writing this fantastic test suite,
to Jean-Pierre Andre for tirelessly working on the port and fixing
countless file system problems over the last half year and to Szeredi
Miklos for his exceptionally rapid FUSE fixes.
Enjoy,
Szaka
--
NTFS-3G: http://ntfs-3g.org
ext4: update ctime and mtime for truncate with extents.
From: Solofo Ramangalahy <[email protected]>
The recently announced "Linux POSIX file system test suite"
catched a truncate issue when using extents:
mtime and ctime are not updated when truncate is successful.
This is the single issue catched with "default" ext4 (mkfs and mount
with minimal options).
The testsuite does not report failure with -o noextents.
With the following patch, all tests of the testsuite passes.
Signed-off-by: Solofo Ramangalahy <[email protected]>
---
fs/ext4/extents.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
===================================================================
--- linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d.orig/fs/ext4/extents.c
+++ linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
@@ -2947,6 +2947,7 @@ out_stop:
ext4_orphan_del(handle, inode);
up_write(&EXT4_I(inode)->i_data_sem);
+ inode->i_mtime = inode->i_ctime = ext4_current_time(inode);
ext4_journal_stop(handle);
}
On Mon, 2008-04-07 at 10:43 +0200, [email protected] wrote:
> ext4: update ctime and mtime for truncate with extents.
>
> From: Solofo Ramangalahy <[email protected]>
>
> The recently announced "Linux POSIX file system test suite"
> catched a truncate issue when using extents:
> mtime and ctime are not updated when truncate is successful.
>
> This is the single issue catched with "default" ext4 (mkfs and mount
> with minimal options).
> The testsuite does not report failure with -o noextents.
>
> With the following patch, all tests of the testsuite passes.
>
Thanks for the fix.
> Signed-off-by: Solofo Ramangalahy <[email protected]>
>
> ---
> fs/ext4/extents.c | 1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
> ===================================================================
> --- linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d.orig/fs/ext4/extents.c
> +++ linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
> @@ -2947,6 +2947,7 @@ out_stop:
> ext4_orphan_del(handle, inode);
>
> up_write(&EXT4_I(inode)->i_data_sem);
> + inode->i_mtime = inode->i_ctime = ext4_current_time(inode);
Shouldn't we mark inode dirty after the ctime and and mtime is changed?
> ext4_journal_stop(handle);
> }
>
Regards,
Mingming
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Mingming Cao writes:
> Shouldn't we mark inode dirty after the ctime and and mtime is changed?
I should have been more careful when mimicing the non-extent case or
examine more closely the patch queue (I am just noticing
ext4-update-mtime-and-ctime-on-rename.patch). I honestly do not have
a definitive answer now, but I trust you and Jan more than me.
... so, yes, we should.
Looking back at the code, there is actually a pattern
ext4_current_time() followed by ext4_mark_inode_dirty(), but I do not
think it is worth a refactoring.
Attached the updated patch.
Thanks and sorry for the trouble,
--
solofo
ext4: update ctime and mtime for truncate with extents.
From: Solofo Ramangalahy <[email protected]>
The recently announced "Linux POSIX file system test suite"
http://ntfs3g.org/sw/qa/pjd-fstest-20080402.tgz catched a truncate
issue when using extents:
mtime and ctime are not updated despite truncate being successful.
This is the single issue catched with "default" ext4 (mkfs and mount
with minimal options).
The testsuite does not report failure with -o noextents.
With the following patch, all tests of the testsuite passes:
Signed-off-by: Solofo Ramangalahy <[email protected]>
---
fs/ext4/extents.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
===================================================================
--- linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d.orig/fs/ext4/extents.c
+++ linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
@@ -2947,6 +2947,8 @@ out_stop:
ext4_orphan_del(handle, inode);
up_write(&EXT4_I(inode)->i_data_sem);
+ inode->i_mtime = inode->i_ctime = ext4_current_time(inode);
+ ext4_mark_inode_dirty(handle, inode);
ext4_journal_stop(handle);
}
On Thu, 2008-04-10 at 15:11 +0200, [email protected] wrote:
> Mingming Cao writes:
> > Shouldn't we mark inode dirty after the ctime and and mtime is changed?
>
> I should have been more careful when mimicing the non-extent case or
> examine more closely the patch queue (I am just noticing
> ext4-update-mtime-and-ctime-on-rename.patch). I honestly do not have
> a definitive answer now, but I trust you and Jan more than me.
>
> ... so, yes, we should.
>
> Looking back at the code, there is actually a pattern
> ext4_current_time() followed by ext4_mark_inode_dirty(), but I do not
> think it is worth a refactoring.
>
> Attached the updated patch.
>
> Thanks and sorry for the trouble,
Np, I updated the patch in the patch queue. BTW, it would be nice to
generate the patch with -p next time to show which function the changes
are modifying.
Mingming
> --
> solofo
>
> ext4: update ctime and mtime for truncate with extents.
>
> From: Solofo Ramangalahy <[email protected]>
>
> The recently announced "Linux POSIX file system test suite"
> http://ntfs3g.org/sw/qa/pjd-fstest-20080402.tgz catched a truncate
> issue when using extents:
> mtime and ctime are not updated despite truncate being successful.
>
> This is the single issue catched with "default" ext4 (mkfs and mount
> with minimal options).
> The testsuite does not report failure with -o noextents.
>
> With the following patch, all tests of the testsuite passes:
>
> Signed-off-by: Solofo Ramangalahy <[email protected]>
>
> ---
> fs/ext4/extents.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
> ===================================================================
> --- linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d.orig/fs/ext4/extents.c
> +++ linux-2.6.25-rc8-git5-ext4-52c7a8013ad2c452551a68ff4daab4bacbe28f9d/fs/ext4/extents.c
> @@ -2947,6 +2947,8 @@ out_stop:
> ext4_orphan_del(handle, inode);
>
> up_write(&EXT4_I(inode)->i_data_sem);
> + inode->i_mtime = inode->i_ctime = ext4_current_time(inode);
> + ext4_mark_inode_dirty(handle, inode);
> ext4_journal_stop(handle);
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html