On Fri, Jan 7, 2011 at 8:29 PM, Chris Mason <chris.mason@xxxxxxxxxx> 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. -- Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
