On Sat, Jan 8, 2011 at 3:40 PM, Olaf van der Spek <olafvds...@gmail.com> wrote: > On Fri, Jan 7, 2011 at 8:29 PM, Chris Mason <chris.ma...@oracle.com> wrote: >> The exact amount of tracking is going to vary. The reason why is that >> actually doing the truncate is an O(size of the file) operation and so >> you can't just flip a switch when the write or the close comes in. You >> have to run through all the metadata of the file and do something >> temporary with each part that is only completed when the file IO is >> actually done. > > That's true. Maybe the proper way, via O_ATOMIC, is better. > >> Honestly, there many different ways to solve this in the application. >> Requiring high speed atomic replacement of individual file contents is a >> recipe for frustration. > > Did you see message of Massimo? That'd be the ideal way from an app > point of view. > Not solving this properly in the FS moves the problem to userspace > where it's even harder to solve and is not as performant. > > Replacing file data is a common operation that IMO the FS should > support in a safe way.
Chris? -- Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
