On Saturday, February 10, 2018 01:46:33 PM Garrett Wollman wrote:
> In article
> asom...@freebsd.org writes:
> >On Sat, Feb 10, 2018 at 10:28 AM, Willem Jan Withagen <w...@digiware.nl>
> >> Is there any expectation that this is going to fixed in any near future?
> >No. It's fundamentally impossible to support posix_fallocate on a COW
> >filesystem like ZFS. Ceph should be taught to ignore an EINVAL result,
> >since the system call is merely advisory.
> I don't think it's true that this is _fundamentally_ impossible. What
> the standard requires would in essence be a per-object refreservation.
> ZFS supports refreservation, obviously, but not on a per-object basis.
> Furthermore, there are mechanisms to preallocate blocks for things
> like dumps. So it *could* be done (as in, the concept is there), but
> it may not be practical. (And ultimately, there are ways in which the
> administrator might manage the system that would defeat the desired
> effect, but that's out of the standard's scope.) Given the semantic
> mismatch, though, I suspect it's unreasonable to expect anyone to
> prioritize implementation of such a feature.
I don't think posix_fallocate() can be compatible with COW. Suppose you
do reserve a fixed set of blocks. That ensures the first write has a
place to write, but not if you overwrite one of those blocks. You'd have
to reserve another block to maintain the reservation each time you wrote
to a block, or you'd have to have a way to mark a file as not COW. The
first case isn't really any better than not using posix_fallocate() in the
first place as you are still requiring writes to allocate blocks, and the
second seems a bit fraught with peril as well if the application is
expecting the non-COW'd file to be in sync with other files in the system
since presumably non-COW'd files couldn't be snapshotted, etc.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"