于 2013年12月15日 02:21, Jean-Pierre André 写道:
> 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é 写道:
>>> 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.
>
> 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.
Yeah, I have talked about it at previous email, the FUSE in kernel will
not set the UID and GID attr flag bits when chown(-1,-1), then the FUSE
fs maybe not call the real chown according the attr flag bits from
kernel, so the ctime will not be changed.
But I think we can't say FUSE fs will never update the ctime when
chown(-1, -1). The behavior of FUSE fs depend on their respective
implement in userspace.
The glusterfs is a FUSE fs, and it update the ctime when I test in
version "3.4.0.40rhs-2.el7.x86_64".
>
>> 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.
>
>
>>
>>> 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.
>
> 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
>>> ;;
>>> 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 :)
>
> I confirm this. Same for btrfs.
If you can sure that the btrfs also can be tested by use pjd-fstest, I
will told our btrfs-qe, suggest they use it.
>
>>> - 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 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.
That's nice, thank you. I will test the glusterfs again tonight (after
7 hours) by use your newest attachment, now I need to take a train, and
can't connect my gluster server.
Thank you for your reply:)
Zorro Lang
>
>>>
>>> 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
