Just to close the loop, I just made a branch named HDFS-13572 to match the
new non-blocking issue (after some nice encouragement posted up on the
JIRA).
Thanks,
S
On Tue, May 15, 2018 at 9:30 PM, Stack wrote:
> On Fri, May 4, 2018 at 5:47 AM, Anu Engineer
> wrote:
>
>> Hi Stack,
>>
>>
>>
>>
On Fri, May 4, 2018 at 5:47 AM, Anu Engineer
wrote:
> Hi Stack,
>
>
>
> Why don’t we look at the design of what is being proposed? Let us post
> the design to HDFS-9924 and then if needed, by all means let us open a new
> Jira.
>
> That will make it easy to understand
Hi Stack,
Why don’t we look at the design of what is being proposed? Let us post the
design to HDFS-9924 and then if needed, by all means let us open a new Jira.
That will make it easy to understand the context if someone is looking at
HDFS-9924.
I personally believe that it should be the
Will prepare a design doc soon to roughly describe the things we want to do
and how we plan to do it, and also the undecided things, such as how to
support fan-out.
Thanks.
2018-05-04 4:54 GMT+08:00 Anu Engineer :
> Hi St.ack/Wei-Chiu,
>
> It is very kind of St.Ack to
Hi St.ack/Wei-Chiu,
It is very kind of St.Ack to bring this question to HDFS Dev. I think this is a
good feature to have. As for the branch question,
HDFS-9924 branch is already open, we could just use that and I am +1 on adding
Duo as a branch committer.
I am not familiar with HBase code
Given that HBase 2 uses async output by default, the way that code is
maintained today in HBase is not sustainable. That piece of code should be
maintained in HDFS. I am +1 as a participant in both communities.
On Thu, May 3, 2018 at 9:14 AM, Stack wrote:
> Ok with you lot if
Ok with you lot if a few of us open a branch to work on a non-blocking HDFS
client?
Intent is to finish up the old issue "HDFS-9924 [umbrella] Nonblocking HDFS
Access". On the foot of this umbrella JIRA is a proposal by the
heavy-lifter, Duo Zhang. Over in HBase, we have a limited async DFS