On Wed, Jan 26, 2011 at 8:30 PM, Chris Mason <chris.ma...@oracle.com> wrote: > My answer hasn't really changed ;) Replacing file data is a common > operation, but it is still surprisingly complex. Again, the truncate is > O(size of the file) and it is actually impossible to do this atomically > in most filesystems.
Unfortunately life isn't trivial. ;) Given that it's common, it doesn't make sense to have code duplication in lots of apps to implement the temp file rename pattern. If it's too complex to implement in the FS (ATM), would it be possible to implement it in a higher layer? > You don't notice this because xfs/ext34/btrfs (and many others) have > code that makes sure a truncate is restarted if you crash. So, it > appears to be atomic even though we're really just restarting the > operation. In order to have a truncate + replacement of data operation, > we'd have to do a disk format change that includes both the truncate and > the new data. I'm not sure why the disk format would have to change. Conceptually, just like the temp file case, you'd write the new data to newly allocated blocks. After (and I guess that's the complex part) they're safely on disk, you update the meta data, in an atomic way. > It would look a lot like echo data > file.new ; truncate file ; mv > file.new file, but recorded in the FS metadata. > > I don't have this in the btrfs roadmap. It would be nice but most > people use databases for things that require atomic operations. I Executables and files shouldn't be in a DB. 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
