I do know how copy-on-write works. But this seems insufficient to address the problem I asked. One possible way is to modify the filesystem so that when a file is opened for write, we always keep a copy of the file's metadata and a CoW bitmap. For subsequent writes, we first copy the old data to somewhere else in memory for backup, mark the CoW bitmap, and then write to the file. The temporary data is discarded when the file is closed. By checking the CoW bitmap, the backup application can determine which data it should copy to the backup media. This solution can address this problem. But it requires copy-on-write on every write, no matter whether there is a backup operation. I suspect that this solution will impact the system performance (at least write performance) quite a bit and consume more memory. Any further thought? Thanks! On 7/3/07, Sunil Joshi <mail2joshi@xxxxxxxxx> wrote:
It depends how snapshot is being taken. Usually it is Copy On Write. Google for Copy on Write and you will find the answer for this. On 7/3/07, Xin Zhao <uszhaoxin@xxxxxxxxx> wrote: > > Hi, > > > If a file is already opened when snapshot command is issued, the file > itself could be in an inconsistent state already. Before the file is > closed, maybe part of the file contains old data, the rest contains > new data. > How does a versioning filesystem guarantee that the file snapshot is > in a consistent state in this case? > > I googled it but didn't find any answer. Can someone explain it a little bit? > > Thanks > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html