Reiser4 fallocate (was Re: Xattr items)

[Edward Shishkin <edward.shishkin@gmail.com>]

Yeah, it would be nice. This feature is used by various virtualization
technologies, i.e. is rather important.

I think that existing low-level framework is enough to implement it.
So, we need to implement a ->fallocate() method of the regular file
plugin. Actually it will resemble write and truncate file operations.
E.g. in default mode it will look like something between write and
expanding truncate. Specifically ->write() inserts extents, allocates
pages, charges the transaction manager to allocate disk space and
issue IO requests. Expanding truncate only inserts extents. And
->fallocate() should insert extents and charge the transaction manager
to allocate disk space. That "charge" is made by allocating a jnode
(per block), capturing it, and making it dirty. The problem is that by
default our transaction manager will try to issue a write IO request
against such jnode, so we'll need to mark that jnode by some special
way, and to teach the lowest-level IO issuer
(write_jnodes_to_disk_extent) to not issue a write request, but
instead uncapture that jnode and make it clean. Also we'll need a new
state of extents (besides the three existing ones):
ALLOCATED_HOLE_EXTENT. The trouble is that we don't have a dedicated
field to store this new state on disk. I suggest to store it in the
high bits of the extent's width. Thus, we'll need to modify (with
masking, etc) extent_get_width, extent_set_width, state_of_extent in
reiser4 kernel module and reiser4progs. Blocks pointed by extent of
that new state are "reserved", they contain garbage. Any attempts to
read blocks pointed by such extents should not issue read IO requests:
respective pages should be filled by zeros. Attempts to write to a
block of such extent should "plug an allocated hole", see the function
plug_hole() - if we can not reuse it, then let's create a similar
function plug_allocated_hole().

Basically that is all. It can happen that I missed some minor issues
though. If you find it is too complicated, then we'll find more easy
task.

Thanks,
Edward.

On 03/25/2017 11:46 PM, Daniel Horne wrote:
> On 24 March 2017 at 20:26, Edward Shishkin<edward.shishkin@gmail.com>  wrote:
>> Could you have a look at fallocate / hole-punching  support, if
>> interesting? For beginning I would recommend to implement it for
>> files managed by unix-file plugin and built of extent items.
> Ok, I'll take a look at that.
>
> Thanks,
> DH