zhengchenyu commented on PR #4441: URL: https://github.com/apache/hadoop/pull/4441#issuecomment-1157672472
> Thanks @zhengchenyu and @simbadzina . > > > I think config in client side may be more flexible. > > This is a very meaningful topic. If only the client controls whether or not to enable ObserverRead will be more difficult for Admin to control, because it is very difficult to upgrade the HDFS client in full. In other words: If RBF controls whether the ObserverRead is enabled, the Admin will be very convenient to control the ObserverRead of the entire cluster, and even dynamically control whether the ObserverRead of a single NS or the entire cluster is enabled. But there may be some special Client that do not want to enable ObserverRead, so RBF should identify those requests and proxy them to the Active Namenode. > > @simbadzina This is why dynamic updates are required, so that when Admin finds that there are some abnormal Observer NameNodes, he/she can quickly disable the ObserverRead of one NS or even all NSs. > > > In our draft design, after apply [HDFS-13522](https://issues.apache.org/jira/browse/HDFS-13522).002.patch, I wanna proxy client's state id. > > Proxying client's state id to the NameNode by RBF will be very complicated. > > * A DFSClient may read or write some paths of different NameServices, and the stateID of different NS may be different. > * The client does not know the Nameservice to which the reading or writing path belong, so it cannot pass the state id to RBF. Yes, you are right in some condition. If all client are common user, for hive and mr application, it is right. We know observer can not guarantee strong consistency, maybe some use have high demand, they could wanna disable observe read, though few user have this demand. Maybe we can reserve configuration both on router side and client side. Yes, Proxying client's state id is complicated. I don't know whether it is necessary or not. So just delay it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
