On Thu, Mar 31, 2011 at 08:34:50PM -0400, Josef Bacik wrote:
> > More interesting would be to bring the ioctls up to generic code
> > and have them backended by fallocate. I'm not sure they map without
> > looking deeper, but it's at least an idea.
> >
>
> I just did a cursory look and it se
On Thu, Mar 31, 2011 at 04:44:55PM -0700, Joel Becker wrote:
> On Thu, Mar 31, 2011 at 06:56:18PM -0400, Josef Bacik wrote:
> > On Thu, Mar 31, 2011 at 02:14:43PM -0700, Sunil Mushran wrote:
> > > Frankly I see no point extending the ioctl interface when we have
> > > a syscall interface.
> > >
> >
On Thu, Mar 31, 2011 at 06:56:18PM -0400, Josef Bacik wrote:
> On Thu, Mar 31, 2011 at 02:14:43PM -0700, Sunil Mushran wrote:
> > Frankly I see no point extending the ioctl interface when we have
> > a syscall interface.
> >
>
> I'd even go so far as to say we could probably axe the xfs and ocfs2
On Thu, Mar 31, 2011 at 02:14:43PM -0700, Sunil Mushran wrote:
> Frankly I see no point extending the ioctl interface when we have
> a syscall interface.
>
I'd even go so far as to say we could probably axe the xfs and ocfs2 ioctls
since we have the fallocate interface :). Thanks,
Josef
--
To un
Frankly I see no point extending the ioctl interface when we have
a syscall interface.
On 03/31/2011 12:33 AM, Tristan Ye wrote:
We're currently support two paths from VFS to preallocate unwritten
extents(from FS_IOC_RESVSP, or fallocate()), likewise, behavior of
punching-hole should be treated
