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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
