Hi, Today, I have made the change I was suggesting, and tested again all the file systems I could gather :
On Linux : ext3, ext4, xfs, btrfs, ntfs-3g on OpenIndiana (SunOS) : ZFS, UFS, ntfs-3g All of them pass with no error. I just discovered two unexpected (but correct) behaviors in link/00.t on UFS (fixed now). The changed files are attached, can you make a new try on glusterfs, just to be sure I have forgotten nothing ? See also my comments below. Thanks again for your collaboration. Regards Jean-Pierre Zorro Lang wrote:
于 2013年12月14日 01:51, Jean-Pierre André 写道:Oh, I think I have explained all the situations where I made changes on last email.Hi, Zorro Lang wrote:于 2013年12月13日 16:17, Jean-Pierre André 写道:The posix is a standard, GNU/Linux follow this standard, so the filesystem in linux should have same behavior. The glusterfs nearly no difference with other fs, but there are still to things I need to do:Hi, Thanks for the proposed patches. What are the situations where glusterfs should not behave like ext3/ext4 on Linux ?[...] Actually, what I meant, is that in all the situations where you made changes, glusterfs behaves the same as ext3 and xfs on Linux.The ctime changed by linux VFS, so all linux local filesystem must update the ctime. But some fs with FUSE maybe update or not update the ctime.And there are known cases where Solaris file systems or freebsd ones behave differently from Linux ones. So you end up enumerating all file systems, like below. This hides what is specific to an operating system and would require to add cases for ext4 or newer file systems.case "${os}:${fs}" in -Linux:ext3) +Linux:ext3 | Linux:xfs | Linux:glusterfs) test_check $ctime1 -lt $ctime2 ;; -*) +*:ext3 | *:xfs | *:ZFS | *:ntfs-3g | *:UFS) test_check $ctime1 -eq $ctime2 + ;; +*) + test_check $ctime1 -le $ctime2 ;; esac
Actually not, I have checked again. Fuse does not call the file system when uid == gid == -1, so the file system cannot update the ctime.
I haven't test UFS, ZFS and ntfs-3g in Linux, I just knew xfs,ext and glusterfs will use "$ctime1 -lt $ctime2" in linux, and I have made sure that by ask the ext, xfs and glusterfs developer.The original code is: "test_check $ctime1 -eq $ctime2 "So I think all of the $os:$fs which the pjd-fstest supported(in README) will not update the ctime previously. Now I just made sure the ext, xfs, glusterfs in linux, so I just wrote"+Linux:ext3 | Linux:xfs | Linux:glusterfs) test_check $ctime1 -lt $ctime2 " at first. Then I want to keep other situations to use "-eq".Last I use "-le" to delegate "need not" which posix said for others "unclear" situations.
Yes, your proposal is correct, but it can be simplified to make it easier to maintain.
the linux:glusterfs not need to be wrote specifically, it's same with ext3 and xfs in linux. If others fs different from most linux ones, it can be wrote here.So I would suggest writing the above like case "${os}:${fs}" in Linux:glusterfs) # test for glusterfs if it is different from most Linux ones, ;;
Yes of course. What I wrote above was a generic pattern to be adapted to each specific case.
Linux:*) # usual test for Linux ones (ext3, ext4, and usually glusterfs) ;; # specific tests here for other OS when needed *) # tests not applicable to Linux ;; esacAdvantages : - glusterfs would probably not be a special case - special situations for some OS or fs are taken into account - no update is needed for newer file systems (e.g. ext4)when I tested ext4 I often use fs=ext3, and test passed :)
I confirm this. Same for btrfs.
I think maybe we should test all "unclear" situations in all the $os:$fs which the pjd-fstest support(in README or tests/conf), to make sure the current status of every $os:$fs, before public the newest code.- file systems, like ntfs-3g, whose behavior depends on the OS are easily taken into account - changes in behavior of a file system can be detected (and your tests showed a change in ext3 behavior which may have to be propagated to other file systems)
I think I have tested all these cases, and found another unclear one : when a hard link is unsuccessful, UFS does not update the ctime, but all other file systems do, and Posix does not mention ctime on unsuccessful completion.
OK, I have given you my thinking here, I think you can decide how to do the final modification:) If need me to do something I will try my best:)I cannot do this change now, I will make a proposal later.Thank you, Zorro LangRegards Jean-Pierre
updates.tar.gz
Description: application/gzip
------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
