[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] 112092556662141] FRS questions
From: Tarun Chopra <Tarun.Chopra () microsoft ! com>
Date: 2012-10-31 6:03:01
Message-ID: DDBD45A4D7FADF4C892462CA15CEB5B432A3727D () TK5EX14MBXC296 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]
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@samba.org]
Sent: Monday, October 29, 2012 9:04 PM
To: Tarun Chopra
Cc: MSSolve Case Email; cifs-protocol@samba.org; pfif@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@samba.org]
> Sent: Wednesday, October 17, 2012 11:55 PM
> To: Tarun Chopra
> Cc: MSSolve Case Email; cifs-protocol@samba.org; pfif@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@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@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@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@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@samba.org <mailto:mat@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@samba.org]
> > > <mailto:[mailto:mat@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
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic