hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Milind.Bhandar...@emc.com>
Subject Re: [DISCUSS] Remove append?
Date Thu, 22 Mar 2012 23:27:25 GMT

I think by "current definition of visible length", you mean that once a
client opens a file and gets block list, it will always be able to read up
to the length at open.

However, correct me if I am wrong, but this definition is already
violated, if file is deleted after open.

So, truncate does add some complexity, but not a whole lot. If client gets
an EOF before length at open, it must retry to see if the new visible
length is different (rather than to see if the file does not exist

Right ?

- milind

Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)

On 3/22/12 4:03 PM, "Eli Collins" <eli@cloudera.com> wrote:

>On Thu, Mar 22, 2012 at 3:57 PM, Tsz Wo Sze <szetszwo@yahoo.com> wrote:
>>> Do you think having the invariant that blocks are not mutated would
>>> significantly simply the design?
>> No.  As mentioned in my previous email and others, the complexity is in
>>hflush.  Once we have hflush, append is straightforward.
>I understand that append is a small delta once you have hflush, what
>I'm saying is that the overall design of the file system is
>significantly simplified if you can assume blocks are not mutated. Eg
>see the way truncate is going to interact with the current definition
>of visible length (it violates it). Resolving issues like that are

View raw message