Ahmad Humayun wrote:
So does that mean nodes can possibly read files that have been "deleted"
If the name node entry has been deleted, new opens will fail.
Already opened files may have their reads succeed if they have cached
the block locations and also if the
blocks have not been deleted.
Hence, if you open a large file and someone deletes the file after you
open it, at some point the reads may fail if
the client needs to go to the namenode to get block locations.
This not posix semantics but keeping the namenode stateless has
advantages in scaling.
thanks :)
regards,
On Wed, Mar 12, 2008 at 10:57 PM, Hairong Kuang <[EMAIL PROTECTED]>
wrote:
Case 1: Lets say there is a node which opens a file on the DFS to read.
From
my understanding, the open request will go to the namenode, which will
tell
it where the blocks of the file are. What if another node comes up and
asks
to delete that file. Of course this request will go to the namenode. How
will the namenode respond in such a situation?
The namenode is stateless. So the delete request will go through. The
first
request may fail.
Case 2: Whenever a node wants to delete a file, I think the request
first
lands with the namenode? What happens to the replicas of the blocks of
that
file, as soon as that file gets deleted?
The replicas are scheduled to be deleted by the namenode. But there may be
some delay before they are actually deleted on the datanodes.
Hairong
