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

Re: [dm-devel] Re: device mapper integrated loops - and one more year !

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 ;)


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