[dm-devel] Re: device mapper integrated loops - and one more year !
Roland Paterson-Jones
roland at rolandpj.com
Thu Nov 23 11:15:13 UTC 2006
Bryn M. Reeves wrote:
>Roland Paterson-Jones wrote:
>
>
>>... sparse files ...
>>
>>Would you do this by using file ops to lazily fill holes on first write?
>>Is this compatible with S_SWAPFILE? For read purposes, holes can be
>>mapped to zero device, I presume.
>>
>>
>
>That's what I figured - lazy allocation seems to be the main reason that
>sparse files are desirable.
>
>The problem with sparse files is that they make us do something that
>dm-loop is explicitly trying to avoid - calling into the filesystem at
>I/O time.
>
>
I can live with that, as long as it's only a first-write phenomenon.
I.e. first-write of a hole uses file-ops, then sniffs the underlying
device mapping for subsequent ops. Although I guess this could cause the
same OOM regime for a lot of writes on an initially sparse file (or is
this exacerbated by loopbacks elevated priority?).
>There are two ways we can address this. The dm-loop target needs a
>non-bmap based fallback for filesystems that can't use direct mapping
>anyway (e.g. network filesystems).
>
>We can either revert to this mechanism entirely for sparse files (means
>we get many of the drawbacks of regular /dev/loopN), or try to support
>mixed extent types. That's had some thought & discussion but we don't
>have an implementation ready yet.
>
>
I'd be very much in favour of a lazy mixed approach that converges
towards device-only access with substantial use. Otherwise I think I'm
back where I started.
>
>The patch currently on kernel.org uses a table format like this:
><start> <len> loop <path> <offset>
>
>
Thanks. I'll play ;)
Roland
More information about the dm-devel
mailing list