Print

Print


Hi Gerri and Fabrizio,

The problem is that the function is basically broken in the server. The 
current implementation stats each file in the list and the code gets 
confused when a redirection or error occurs. The change should allow me to 
simply report back the status of the cluster from the redirector's viewpoint 
and never redirect the client and continue down the list even if an error 
occurs. Now, from the redirector's standpoint all I know is whether the file 
is online or not. If the file is offline, it may or may not exist (that I 
can't tell). So, the statx would really be only useful for identifying 
online files. Hopefully, that functionality is enough.

Andy

----- Original Message ----- 
From: "Gerardo Ganis" <[log in to unmask]>
To: "Andrew Hanushevsky" <[log in to unmask]>
Cc: "Fabrizio Furano" <[log in to unmask]>; 
<[log in to unmask]>
Sent: Wednesday, August 29, 2007 4:46 AM
Subject: Re: Proposed statx Protocol Change


>
> Hi Andy,
>
> If you think that the change in the flag definition will simplify statx 
> and make more reliable
> that's fine with me.
>
> What made for us (at CAF) the command unusable was what seemed to be an 
> inconsistency
> in the result (I've sent to you an example a few weeks ago).
>
> Is there someone using extensively statx with large number of files 
> (O(1000)) ?
>
> Gerri
>
> Fabrizio Furano wrote:
>
>> Hi all,
>>
>>  afaik the only problem I am aware of (if it's stuill there) was that at 
>> some point the server returnde an error if one of the files did not 
>> exist. This obviously screwed up the meaning of statx.
>>
>>  From my opint of view I don't need to change the flag set with an 
>> equivalent one, since the wrapping in XrdClientAdmin takes care of those 
>> flags and is quite consolidated (except in the case the server returns 
>> errors instead of flags). But I ignore if there is some other reason.
>>
>> Fabrizio
>>
>>
>> Andrew Hanushevsky wrote:
>>
>>> As we all probably know, there have been several complaints about statx. 
>>> It's been a very problematic protocol element. In order to simplify it 
>>> and make it more consistent I'd like to change the meaning of the flags 
>>> whch would them allow an implementation that makes sense,
>>>
>>> The currently returned flags are:
>>> flags    identifies the entry's attributes as a binary character. The 
>>> entry should be assumed to be an immediately available regular file 
>>> unless one or more of the following bits are set.
>>>
>>>        kXR_xset         - Either an executable file or a searchable 
>>> directory.
>>>
>>>        kXR_isDir      - This is a directory.
>>>
>>>        kXR_other      - This neither a file nor a directory, or does not 
>>> exist.
>>>
>>>  kkXR_offline - For files, the file is not online (i.e., on disk).
>>>
>>>        I would like to change it to be:
>>>
>>> kXR kXR_exists     - Object exists and is either an file or a directory.
>>>
>>>        kXR_offline - For files, the file is not online (i.e., on disk).
>>>
>>> Any  Hence, the object does not exist if all the bits are set to zero. I 
>>> can make the corresponding client code changes to ease the effort. 
>>> Anyone would rather not?
>>>
>>> a       Andy
>>>
>
>