Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS, mail # dev - Why datanode does a flush to disk after receiving a packet


Copy link to this message
-
Re: Why datanode does a flush to disk after receiving a packet
Hairong Kuang 2010-11-11, 19:55
A few clarification on API2 semantics.

1. Ack gets sent back to the client before a packet gets written to local
files.
2. Data become visible to new readers on the condition that at least one
DataNode does not have an error.
3. The reason that flush is done after a write is more for the purpose of
implementation simplification. Currently readers do not read from DataNode
buffer. They only read from system buffer. A flush makes the data visible to
readers sooner.

Hairong

On 11/11/10 7:31 AM, "Thanh Do" <[EMAIL PROTECTED]> wrote:

> Thanks Todd,
>
> In HDFS-6313, i see three API (sync, hflush, hsync),
> And I assume hflush corresponds to :
>
> *"API2: flushes out to all replicas of the block.
> The data is in the buffers of the DNs but not on the DN's OS buffers.
> New readers will see the data after the call has returned.*"
>
> I am still confused that, once the client calls hflushes,
> the client gonna wait for all outstanding packet to be acked,
> before sending subsequent packet.
> But at DataNode, it is possible that the ack to client is sent
> before the write of data and checksum to replica. So if
> the DataNode crashes just after sending the ack and before
> writing to replica, will the semantics be violated here?
>
> Thanks
> Thanh
>
> On Wed, Nov 10, 2010 at 11:11 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
>> Nope, flush just flushes the java side buffer to the Linux buffer
>> cache -- not all the way to the media.
>>
>> Hsync is the API that will eventually go all the way to disk, but it
>> has not yet been implemented.
>>
>> -Todd
>>
>> On Wednesday, November 10, 2010, Thanh Do <[EMAIL PROTECTED]> wrote:
>>> Or another way to rephase my question:
>>> does data.flush and checksumOut.flush guarantee
>>> data be synchronized with underlying disk,
>>> just like fsync().
>>>
>>> Thanks
>>> Thanh
>>>
>>> On Wed, Nov 10, 2010 at 10:26 PM, Thanh Do <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After reading the appenddesign3.pdf in HDFS-256,
>>>> and looking at the BlockReceiver.java code in 0.21.0,
>>>> I am confused by the following.
>>>>
>>>> The document says that:
>>>> *For each packet, a DataNode in the pipeline has to do 3 things.
>>>> 1. Stream data
>>>>       a. Receive data from the upstream DataNode or the client
>>>>       b. Push the data to the downstream DataNode if there is any
>>>> 2. Write the data/crc to its block file/meta file.
>>>> 3. Stream ack
>>>>       a. Receive an ack from the downstream DataNode if there is any
>>>>       b. Send an ack to the upstream DataNode or the client*
>>>>
>>>> And *"...there is no guarantee on the order of (2) and (3)"*
>>>>
>>>> In BlockReceiver.receivePacket(), after read the packet buffer,
>>>> datanode does:
>>>> 1) put the packet seqno in the ack queue
>>>> 2) write data and checksum to disk
>>>> 3) flush data and checksum (to disk)
>>>>
>>>> The thing that confusing me is that: the streaming of ack does not
>>>> necessary depends on whether data has been flush to disk or not.
>>>> Then, my question is:
>>>> Why do DataNode need to flush data and checksum
>>>> every time the DataNode receives a packet. This flush may be costly.
>>>> Why cant the DataNode just batch server write (after receiving
>>>> server packet) and flush all at once?
>>>> Is there any particular reason for doing so?
>>>>
>>>> Can somebody clarify this for me?
>>>>
>>>> Thanks so much.
>>>> Thanh
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>