[sheepdog] [PATCH v10 06/19] sheep: introduce sparse objects

[Liu Yuan]

On Tue, Jun 17, 2014 at 02:16:48PM +0800, Liu Yuan wrote:
> On Tue, Jun 03, 2014 at 12:09:00AM +0900, Hitoshi Mitake wrote:
> > We don't need to care about a fragmentation when
> >  - the object is unlikely to be accessed sequentially, and

This is wrong assumption, many application do access volume sequentially like
stream based APP(audio, vedio, etc.).

> >  - the object is read-only.
> > 
> > In that sense, we can make the objects sparse if they are not data
> > objects and writable ones.
> > 
> > This fixes the problem that sheepdog consumes many disk spaces for
> > deleted vdi objects if your filesystem supports FALLOC_FL_PUNCH_HOLE.
> 
> I don't understand this patch. If we want sparse objects, we can just stop
> preallocation and no need to trim objects in the hottest path. Am I missing
> anything in the sense that in one way, we preallocate the whole object, but in
> the other we punch hole of objects.
> 

Probably we should only make sparse of deleted inode objects, which is a
placeholder and no pratical use. But for other objects, we should preallocate to
avoid fragmentation and never try to trim objects in the hottest IO pathes. As
far as I remember, trimming functions are problematic for erasure coding and
cluster snapshot. Is this well-tested with EC and sha1 stuff?

Thanks
Yuan