Re: Re: device mapper integrated loops - and one more year !

[Roland Paterson-Jones <roland@rolandpj.com>]

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