Date: Fri, 1 Jul 2016 01:08:06 +0000 (UTC) From: Julian Hsiao <julian@hsiao.email> To: freebsd-hackers@freebsd.org Subject: Re: ggatel(8) extension for binding multiple files Message-ID: <loom.20160701T030511-173@post.gmane.org> References: <nl2eii$ukl$1@ger.gmane.org> <20160630160040.279fc306@fabiankeil.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20160701T030511-173>