ggatel(8) extension for binding multiple files

[Fabian Keil]

Julian Hsiao <julian at hsiao.email> wrote:

> I've been working on extending ggatel(8) to support binding multiple files
> to one device, similar to how sparse bundles work on OS X.  You could
> simulate the functionality with ggatel(8) / md(4) + gconcat(8), but this
> scales poorly when you have 10^5 files.  I've got a working prototype that
> passes some simple tests I wrote.  I also tried using it as backing store
> for UFS and ZFS, copied /usr/{src,obj} over, and ran make build world (with
> ZFS followed by zpool scrub).
> 
> To use it, instead of passing a file to ggatel(8) as the last argument,
> pass a directory with files numerically named in hex (i.e. 0, 1, 2 ..., 9,
> a, b, ..., e, f, 10, 11, ...).
> 
> So, I think it's a good time to gauge the community's interest in this
> feature and whether it'd be possible to merge it to trunk.

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

Even using gvirstor sounds like less maintenance hassle to me.

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

Fabian

[0] Patch 042 in:
https://www.fabiankeil.de/sourcecode/electrobsd/ElectroBSD-r295083-0c7f4d6.diff
(The patch set is out of date, but the ggate[cd]-related patches should still apply.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20160630/acd31fdb/attachment.sig>