Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Apr 2011 12:37:13 -0700
From:      mdf@FreeBSD.org
To:        FreeBSD Arch <freebsd-arch@freebsd.org>
Subject:   Re: posix_fallocate(2)
Message-ID:  <BANLkTinYLh8HyCgZNpEbVsn4hF4s=c-8wg@mail.gmail.com>
In-Reply-To: <BANLkTimYzJ11w9X1OHShEn2wi6gjHx=YjA@mail.gmail.com>
References:  <BANLkTimYzJ11w9X1OHShEn2wi6gjHx=YjA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 14, 2011 at 12:35 PM,  <mdf@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.htm=
l
>
> 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. =A0I didn't see this syscall in NetBSD or
> OpenBSD, so I plan to add it to the end of our syscall table.

I should note that I have a bunch of unit tests as well, but they're
currently using $WORK's test harness, so I plan to figure out how to
re-write them into the existing prove(1) harness.

Thanks,
matthew

>
> What I wanted to check with -arch about was:
>
> 1) is there still a desire for this syscall?
> 2) is this naive implementation useful enough to serve as a default
> for all filesystems until someone with more knowledge fills them in?
> 3) are there any obvious bugs or missing elements?
>
> Thanks,
> matthew
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinYLh8HyCgZNpEbVsn4hF4s=c-8wg>