@Eli, Removing a feature would simplify the design and code. I think this is a generally true statement but not specific to Append. The question is whether Append is useless and it should be removed? I think it is clear from this email thread that the answer is no.
@Milind, I agree with you. BTW, we are proposing truncate on closed file. So it is nothing to do with visible length. Regards, Nichlas ----- Original Message ----- From: "milind.bhandar...@emc.com" <milind.bhandar...@emc.com> To: hdfs-dev@hadoop.apache.org; szets...@yahoo.com Cc: Sent: Thursday, March 22, 2012 4:27 PM Subject: Re: [DISCUSS] Remove append? Eli, 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 anymore). 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" <e...@cloudera.com> wrote: >On Thu, Mar 22, 2012 at 3:57 PM, Tsz Wo Sze <szets...@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 >non-trivial. > >Thanks, >Eli >
