Date: Sat, 10 Feb 2018 13:46:33 -0500 (EST) From: Garrett Wollman <wollman@hergotha.csail.mit.edu> To: asomers@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: posix_fallocate on ZFS Message-ID: <201802101846.w1AIkX4Y000167@hergotha.csail.mit.edu> References: <CAOtMX2jZr_kvJgOZWeiB-AZ3-7-uUu%2BUQ3P0nKhGZ0eNRzwMOQ@mail.gmail.com> <1e2f43fd-85da-6629-62d1-6e96790278e5@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <CAOtMX2jZr_kvJgOZWeiB-AZ3-7-uUu+UQ3P0nKhGZ0eNRzwMOQ@mail.gmail.com>, asomers@freebsd.org writes: >On Sat, Feb 10, 2018 at 10:28 AM, Willem Jan Withagen <wjw@digiware.nl> >wrote: >> 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. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201802101846.w1AIkX4Y000167>