posix_fallocate(2)

mdf at FreeBSD.org mdf at FreeBSD.org
Thu Apr 14 22:41:32 UTC 2011


On Thu, Apr 14, 2011 at 2:36 PM, Gleb Kurtsou <gleb.kurtsou at gmail.com> wrote:
> On (14/04/2011 12:35), mdf at FreeBSD.org wrote:
>> For work we need a functionality in our filesystem that is pretty much
>> like posix_fallocate(2), so we're using the name and I've added a
>> default VOP_ALLOCATE definition that does the right, but dumb, thing.
>>
>> The most recent mention of this function in FreeBSD was another thread
>> lamenting it's failure to exist:
>> http://lists.freebsd.org/pipermail/freebsd-ports/2010-February/059268.html
>>
>> The attached files are the core of the kernel implementation of the
>> syscall and a default VOP for any filesystem not supporting
>> VOP_ALLOCATE, which allows the syscall to work as expected but in a
>> non-performant manner.  I didn't see this syscall in NetBSD or
>> OpenBSD, so I plan to add it to the end of our syscall table.
>>
>> What I wanted to check with -arch about was:
>>
>> 1) is there still a desire for this syscall?
> It looks not to play well architecturally with modern COW file systems
> like ZFS and HUMMER. So potentially it can be implemented only for UFS.

The syscall, or the dumb implementation?  I don't see why the syscall
itself would be a problem; presumably ZFS can figure out whether an
fallocate() block is worth COWing or not...

>> 2) is this naive implementation useful enough to serve as a default
>> for all filesystems until someone with more knowledge fills them in?
> Maillist ate the patch. Only man page attached.

Whoops!

http://people.freebsd.org/~mdf/bsd-fallocate.diff

Cheers,
matthew


More information about the freebsd-arch mailing list