于 2013年12月14日 01:51, Jean-Pierre André 写道:
> Hi,
>
> Zorro Lang wrote:
>> 于 2013年12月13日 16:17, Jean-Pierre André 写道:
>>> Hi,
>>>
>>> Thanks for the proposed patches.
>>>
>>> What are the situations where glusterfs should not behave
>>> like ext3/ext4 on Linux ?
>> 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:
>
> [...]
>
> Actually, what I meant, is that in all the situations where
> you made changes, glusterfs behaves the same as ext3
> and xfs on Linux.
>
Oh, I think I have explained all the situations where I made changes on
last email.
> 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
>
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.
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.
> 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,
> ;;
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.
> Linux:*)
> # usual test for Linux ones (ext3, ext4, and usually glusterfs)
> ;;
> # specific tests here for other OS when needed
> *)
> # tests not applicable to Linux
> ;;
> esac
>
> Advantages :
> - 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 :)
> - 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 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.
>
> I cannot do this change now, I will make a proposal
> later.
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:)
Thank you,
Zorro Lang
>
> Regards
>
> Jean-Pierre
>
>
------------------------------------------------------------------------------
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
