[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [lvm-devel] [PATCH v1 00/30] Ext4 snapshots



On Mon, Jun 13, 2011 at 4:11 PM, Lukas Czerner <lczerner redhat com> 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]