On Sat, May 8, 2010 at 9:40 PM, Amir G. <amir73il@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, May 8, 2010 at 7:25 PM, <tytso@xxxxxxx> wrote: >> >> Technically speaking, it's possible to do it both way, yes? I'm not >> sure why you consider this such a important design decision. We can >> even play games where for some files we might do copy-on-write, and >> for some files, we do move-on-write. It's always possible to check >> the COW bitmaps to decide what had happened. >> > > Definitely yes! I never thought it would really have to come down to a > "decision", > because there is a trade-off at hand. > Even in Next3, without extents, it makes sense to have a choice of > write performance vs. fragmentation per file. > The few applications that use random in-place write (db, virtual disk) > would probably want to avoid the fragmentation. > There is another challenge concerning COW of non-journaled data blocks. With COW of metadata blocks, the order of I/O is guarantied to preserve snapshot consistency after crash, because snapshot data blocks (the copied block) are ordered and both snapshot metadata blocks and original COWed metadata block are journaled in the same transaction. With move-on-write of non-journaled data blocks, the entire move block operation is journaled, the snapshot data block is a moved block, so has no I/O at all, and the new data block is whatever (ordered,writeback). If Next3 were to implement COW of non-journaled data blocks (i.e., ordered or writeback) to avoid the file fragmentation, how can it assure the correct order of I/O between the COWed data block and the snapshot copied block without using synchronic I/O? Can someone propose a solution to that challenge? Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
