On Wed, 25 Oct 2006 11:19 AM, David Chinner wrote: > On Tue, Oct 24, 2006 at 11:26:26AM -0500, Dave Kleikamp wrote: > > On Wed, 2006-10-25 at 02:01 +1000, David Chinner wrote: > > > On Tue, Oct 24, 2006 at 09:51:41AM -0500, Dave Kleikamp wrote: > > > The allocation interface needs to be be able to be extended > > > independently of the data mover interface. XFS already exposes > > > allocation ioctls to userspace for preallocation and > we've got plans > > > to extnd this further to allow userspace controlled allocation for > > > smart defrag tools for XFS. Tying allocation to the data mover > > > just makes the interface less flexible and harder to do anything > > > smart with.... > > > > Okay. It would be nice to standardize the interface so we > don't have > > every filesystem introducing new ioctls. > > Well, that will be an interesting challenge. I'm sure that there > is a common subset that all filesystems can implement e.g. per > file preallocation (something like XFS's allocate/reserve/free space > ioctls) to provide kernel support for posix_fallocate(), etc. > > However, we may end up exposing enough of XFS's current allocation > semantics to do things like telling the filesystem to allocate in > allocation group 6, near block number 0x32482 within the AG, falling > back to searching for the nearest match to the size requirement, > failing that look for something larger than the minimum size > specified, and then fail if you can't find a match in that AG. > > That makes little sense to any filesystem but XFS, which is really > why I think that the smarter allocation interfaces are going to > remain filesystem specific.... Could we have a more abstract method for asking the filesystem where the free blocks are and then using the same block addressing to tell the fs where to allocate/move the file's data to? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
