[cifs-protocol] 112092556662141] FRS questions

Tarun Chopra Tarun.Chopra at microsoft.com
Wed Oct 31 00:03:01 MDT 2012


Hi Matthieu

Regarding your follow up query " Just to be sure, the CO_FLAG_INSTALL_INCOMPLETE is set in the windows implementation of the protocol as it's not transmitted to the upstream there is no obligation for alternative implementation ?" -- Yes, CO_FLAG_INSTALL_INCOMPLETE  is not sent to upstream. The purpose of it is to indicate outbound log not to delete the staging file when the change order is not installed yet. Once the install is done, we clear this flag.

I hope this resolves your query and it's Ok to close the case, please confirm.

Thanks
Tarun


-----Original Message-----
From: Matthieu Patou [mailto:mat at samba.org] 
Sent: Monday, October 29, 2012 9:04 PM
To: Tarun Chopra
Cc: MSSolve Case Email; cifs-protocol at samba.org; pfif at tridgell.net
Subject: Re: 112092556662141] FRS questions

On 10/18/2012 11:31 PM, Tarun Chopra wrote:
> Hi Matthieu
>
> Thanks for your inputs. Yes, we are working on documenting the behavior and will update once document gets an update.
>
> Regarding this " Just to be sure so if the upstream set the flag indicating that the update is done the downstream partner will send the CMD_REMOTE_CO_DONE with the flag   CO_FLAG_INSTALL_INCOMPLETE ?"
> <Reply >: The flag indicating the update is done is set by the downstream not upstream. CO_FLAG_INSTALL_INCOMPLETE is set temporarily to ensure that the staging file is not deleted. It is later cleared during cleanup process on downstream. Hence, it is not sent to upstream. When the update fails for the first time due to lack of space in staging area ( that is the scenario under discussion here), it sends request for space generation and a retry request locally which updates the logs and sends acknowledgement to the upstream.
Just to be sure, the CO_FLAG_INSTALL_INCOMPLETE is set in the windows implementation of the protocol as it's not transmitted to the upstream there is no obligation for alternative implementation ?
> Please let me know if this answers your #1 query.
If so then, "Yes"

Matthieu.
>
> Thanks
> Tarun Chopra.
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat at samba.org]
> Sent: Wednesday, October 17, 2012 11:55 PM
> To: Tarun Chopra
> Cc: MSSolve Case Email; cifs-protocol at samba.org; pfif at tridgell.net
> Subject: Re: 112092556662141] FRS questions
>
> On 10/12/2012 08:41 AM, Tarun Chopra wrote:
>> Hi Matthieu : Would like to check if you have any further query on this issue.
>>
>> -----Original Message-----
>> From: Tarun Chopra
>> Sent: Friday, October 05, 2012 9:10 AM
>> To: 'mat at samba.org'
>> Cc: MSSolve Case Email
>> Subject: RE: 112092556662141] FRS questions
>>
>> Hi Matthieu:
>>
>> Please find details below on the queries:
>>
>> #1 : The file system is full?
>> Downstream partner will set CO_FLAG_INSTALL_INCOMPLETE flag and it does a retrial to write to the file locally. If a flag indicating the VV update is done then, it sends the CMD_REMOTE_CO_DONE command to upstream.
> Just to be sure so if the upstream set the flag indicating that the update is done the downstream partner will send the CMD_REMOTE_CO_DONE
> with the flag   CO_FLAG_INSTALL_INCOMPLETE ?
>
>> #2 : The file system is not full, but it encountered an error in storing the block (say the file has been removed ..)?
>> There is no retrial happening as this is considered as a non-recoverable error. The CO_FLAG_INSTALL_INCOMPLETE flag is not set here, downstream simply aborts this request and frees the packet.
> Ok it's clear.
>
>> Please let me know if it resolves your queries.
> Should the two behavior be documented ?
>> Thanks
>> Tarun Chopra.
>>
>> -----Original Message-----
>> From: Tarun Chopra
>> Sent: Thursday, October 04, 2012 10:35 AM
>> To: mat at samba.org
>> Cc: MSSolve Case Email
>> Subject: RE: 112092556662141] FRS questions
>>
>> Matthieu: Please disregard the below response. I am working internally to share the exact processing rule. Will keep you posted on the progress.
>>
>> -----Original Message-----
>> From: Matthieu Patou [mailto:mat at samba.org]
>> Sent: Thursday, October 04, 2012 10:09 AM
>> To: Tarun Chopra
>> Cc: MSSolve Case Email
>> Subject: Re: 112092556662141] FRS questions
>>
>> Tarun,
>>
>> I still didn't had the time to read carefully this, I hope this week end will allow me this (not so sure).
>>
>> I'll contact you by end of next week on this subject.
>>
>> Matthieu.
>>
>> On 09/25/2012 10:42 AM, Tarun Chopra wrote:
>>> Hi Matthieu
>>>
>>> Per my initial analysis, section 3.3.4.4.7 of MS-FRS1 has following 
>>> details which states that the downstream partner will either receive 
>>> ABORT_FETCH or RETRY_FETCH packet if there is an error in sending 
>>> the file. Downstream partner has to follow processing rules defined 
>>> for this specific commands in order to proceed further. I will 
>>> discuss this in person with you also, please let me know if this 
>>> addresses your query:
>>>
>>> /The downstream partner will receive the CMD_ABORT_FETCH (see 
>>> section
>>> 3.3.4.4.10) or CMD_RETRY_FETCH (see section 3.3.4.4.11) packet if 
>>> the upstream partner is unable to handle the CMD_SEND_STAGE packet 
>>> for any of the following reasons. /
>>>
>>> //
>>>
>>> /When the upstream partner receives the CMD_SEND_STAGE request then 
>>> the out connection MUST be in JOINED state. If the connection is not 
>>> in JOINED state then server MUST send CMD_RETRY_FETCH back to 
>>> downstream partner. The downstream partner MUST perform the initial 
>>> sync and then send a CMD_SEND_STAGE to the upstream partner./
>>>
>>> //
>>>
>>> /If the upstream partner is unable to access the staging file due to 
>>> ERROR_SHARING_VIOLATION then the upstream partner MUST send a 
>>> CMD_RETRY_FETCH back to the downstream partner./
>>>
>>> //
>>>
>>> /If the staging file is missing then the upstream partner MUST try 
>>> to generate the missing staging file. If the upstream partner is 
>>> unable to create a missing staging file with ERROR_DISK_FULL then 
>>> the upstream partner MUST send CMD_RETRY_FETCH to the downstream partner.
>>> ERROR_DISK_FULL is also generated when the staging quota is reached 
>>> for the replica set; the error goes away when staging quota is 
>>> increased manually or staging cleanup is done by the upstream partner.
>>> If the upstream partner fails to create the staging file because of 
>>> any other failure (such as an ACCESS_DENIED error) then the upstream 
>>> partner MUST send a CMD_ABORT_FETCH to the downstream partner. /
>>>
>>> //
>>>
>>> /If the upstream partner is unable to fetch the staging file because 
>>> it has already been deleted then the upstream partner MUST send a 
>>> CMD_RETRY_FETCH to the downstream partner, which will cause the file 
>>> to be recreated on the next CMD_SEND_STAGE request from the 
>>> downstream partner. /
>>>
>>> //
>>>
>>> /If the upstream partner is unable to read the file due to file 
>>> corruption then the upstream partner MUST delete the corrupted file 
>>> and send CMD_RETRY_FETCH to the downstream partner, which will cause 
>>> the file to be recreated on the next CMD_SEND_STAGE request from the 
>>> downstream partner./
>>>
>>> Thanks
>>>
>>> Tarun
>>>
>>> -----Original Message-----
>>> From: Tarun Chopra
>>> Sent: Tuesday, September 25, 2012 9:19 AM
>>> To: Sreekanth Nadendla; mat at samba.org
>>> Cc: MSSolve Case Email
>>> Subject: [RE: 112092556662141] FRS questions
>>>
>>> Hi Matthieu
>>>
>>> I am researching this for you.
>>>
>>> Thanks
>>>
>>> Tarun.
>>>
>>> -----Original Message-----
>>>
>>> From: Sreekanth Nadendla
>>>
>>> Sent: Tuesday, September 25, 2012 8:49 AM
>>>
>>> To: mat at samba.org <mailto:mat at samba.org>
>>>
>>> Cc: MSSolve Case Email
>>>
>>> Subject: 112092556662141 FRS questions
>>>
>>> Dochelp to bcc
>>>
>>> Casemail to cc
>>>
>>> Hello Matthieu,
>>>
>>>                                   Thank you for your inquiry about 
>>> MS-FRS protocol. We have created incident 112092556662141 to track 
>>> this request. One of the Open specifications team member will 
>>> contact you shortly.
>>>
>>> Regards,
>>>
>>> Sreekanth Nadendla
>>>
>>> Microsoft Windows Open Specifications
>>>
>>> -----Original Message-----
>>>
>>> From: Matthieu Patou [mailto:mat at samba.org] 
>>> <mailto:[mailto:mat at samba.org]>
>>>
>>> Sent: Tuesday, September 25, 2012 2:49 AM
>>>
>>> To: Interoperability Documentation Help
>>>
>>> Subject: FRS questions
>>>
>>> Dear dochelp,
>>>
>>> I was looking at the paragraph 3.3.4.4.8 COMM_COMMAND Is 
>>> CMD_RECEIVING_STAGE in MS-FRS1.pdf, I'm wondering what the 
>>> downstream partner should do if it had a problem receiving the chunk 
>>> (ie. the chunk has been removed or the filesystem is full).
>>>
>>> To my understanding the documentation didn't provide any hints to 
>>> what the downstream partner should do. Can you clarfify this point ?
>>>
>>> Thanks.
>>>
>>> Matthieu Patou
>>>
>>> --
>>>
>>> Matthieu Patou
>>>
>>> Samba Team
>>>
>>> http://samba.org
>>>
>> --
>> Matthieu Patou
>> Samba Team
>> http://samba.org
>>
>>
>
> --
> Matthieu Patou
> Samba Team
> http://samba.org
>
>


--
Matthieu Patou
Samba Team
http://samba.org



More information about the cifs-protocol mailing list