On Mon, Jun 13, 2011 at 4:11 PM, Lukas Czerner <lczerner@xxxxxxxxxx> wrote: > On Mon, 13 Jun 2011, Amir G. wrote: > -snip- >> >> >> >> Did you come to understand the drawbacks of multisnap (physical fragmentation)? >> > >> > Yes I did, but the fragmentation is problem for any thinly provisioned >> > storage. I also understand that your snapshot files has also proble with >> > fragmentation. >> > >> >> It's true. ext4 snapshots generates fragmented *files*, but it does not fragment >> the filesystem metadata. And only on specific workloads of in-place writes, >> like large db or virtual image. >> >> One difference is that ext4 snapshots can do effective auto defrag by using >> the inode context, which is not available for multisnap. > > No it is not, but from top of my head .. we can use time locality to > pack frequently accessed blocks together. Definitely there is a place > for improvements. > >> The other big difference is that ext4 snapshots gives precedence to main >> fs performance, while multisnap hasn't even the notion of a main fs. >> All thinp and snapshot targets are writable and get equal treatment. > > I am sorry, what do you mean by that ? Is it that when you mount the > snapshot, the reads will actually have lower importance ? > with ext4, snapshots reads may cause extra seeks, but main fs will stay optimized for reads. with thinp and multisnap, there is no optimization for read from one specific target, but I admit that can change in the future when auto defrag heuristics are applies to multisnap. 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
