ggatel(8) extension for binding multiple files

[Julian Hsiao]

Fabian Keil <freebsd-listen <at> fabiankeil.de> writes:

> In what situation do you think this is preferable to simply using
> a single sparse file or zvol as backing store?

You pretty much said it: when you can't use ZFS. More specifically, when
your backup destination isn't on ZFS, so you have to use something like
rsync for backups. Even with a sparse file, rsync would still have to scan
the entire file, whereas with multiple files it could skip over unmodified
files quickly based on mtime. Perhaps rsync supports lseek(SEEK_HOLE), but
other tools might not.

> Even using gvirstor sounds like less maintenance hassle to me.

Almost none of the geom classes will accept a plain file as a provider,
including gvirstor, so we're back to GEOM-ifying with ggatel or md first.

AFAIK, only ggatel, md, ctl, and zfs would accept plain files in lieu of
character devices.

Finally, gvirstor has some deficiencies per its man page, so I'd rather not
use it.

>> Known issues:
>> [...]
>>   - Both ggatel(8) and md(4) implement BIO_DELETE by zeroing the
>>     requested range. However, this interacts poorly with ZFS since it
>>     BIO_DELETEs the entire device at pool creation. I know there is a
>>     ZFS sysctl to disable the behavior, but I think the device should
>>     just not advertise support if it had to fake it anyway, so I didn't
>>     implement it.
> 
> In ElectroBSD, ggated writes zeros for BIO_DELETEs[0] and as far as I'm
> concerned this interacts rather well with ZFS as ZFS will convert the
> zeros back to BIO_DELETEs (if any compression is enabled) and thus the
> intended effect is achieved.
> 
> I suspect that the reason why it may perform poorly with ggatel is that
> IIRC ggatel does not use a request queue and worker threads and thus
> performs poorly in general (compared to ggatec/ggated).

Sure, the interaction could work out favorably, but BIO_DELETE is still
being simulated, and it just so happens that the simulated behavior maps
to the underlying FS's logic for issuing BIO_DELETE. According to the
comments in the patch you linked, this also only happens with compression
enabled (which admittedly is probably the common case).

In any case, changing my code to conform is pretty simple, and I can add an
option to control the behavior.

Julian Hsiao