rename vfs_preallocate to vfs_preallocate_xfs

James Peach jorgar at gmail.com
Thu Mar 22 15:35:28 GMT 2007


On 22/03/07, Bjoern Jacke <bjoern at j3e.de> wrote:
> On Thu, Mar 22, 2007 at 07:22:10AM -0700, James Peach wrote:
> > On 22/03/2007, at 5:29 AM, Bjoern Jacke wrote:
> >
> > >Hi,
> > >
> > >as Linux is about to get a generic preallocate I would suggest to
> > >rename
> > >the vfs_preallocate to vfs_preallocate_xfs to point out that this
> > >is the
> > >xfs-only preallocate module. James and all, what do you think?
> >
> > Why don't you just add the generic preallocation path to it?
>
> it is not yet available and will only work with future kernels.

configure at build time, then disable it at runtime if it returns ENOSYS.

> In addition to that - isn't the move of stuff like that into the vfs layer
> done to be able to switch between different implementations (for example
> generic posix acls and nfs4 acls ...).

This isn't the only reason to move things into a VFS module. In the
case of prealloc, it is a must-have feature for a small set of users,
but the vast majority don't care. This is why it does not belong in
the main daemon code.

I don't want preallocation modules to proliferate. I would much prefer
that the prealloc module just worked without the admin having to mess
with it. Ideally, if there are filesystem-specific preallocation
methods in it, they would only enable themselves on the appropriate
filesystem.

> With the same argument I would
> like to be able to let users decide which preallocation method to use:
> the XFS ioctl or the future generic one.

I think you mean the future generic one on Linux. I don't know of any
generic call that will work for all platforms. The fewer knobs we have
in Samba the better. The prealloc module should just work in as many
cases as possible without the admin having to do extra configuration.

-- 
James Peach | jorgar at gmail.com


More information about the samba-technical mailing list