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 >
