On Fri, 2006-11-03 at 09:59 +1100, David Chinner wrote: > Let me get this straight - the interface you propose for > moving data about is: > > read and process extents into an internal structure > find range where you want to relocate > find free space you want to relocate into > write desired block to alloc_goal > seek to allocation offset in data/alloc > write length into data/alloc > allocate new inode > write new inode number into data/reloc to relocate blocks > > What I proposed: > > fcntl(src, FIBMAP); > /* find range to relocate */ > open(tmp, O_CREATE); > funlink(tmp); > fs_get_free_list(src, policy, list); > /* select free extent to use */ > fs_allocate_space(tmp, list[X], off, len); > fs_move_data(src, tmp, off, len); > close(tmp); > close(src); > > So the process is pretty close to the same except the interface I > proposed does not change the location of the inode holding the data. > The major difference is that one implementation requires 3 new > generically useful syscalls, and the other requires every filesystem > to implement a metadata filesystem and require root priviledges > to use.
I agree with Dave here. The metadata filesystem will require a lot of overhead (and a lot of code) both in the kernel and in user-space. The only benefit I see, is that it can be easily extended. This may be useful for debugging and prototyping, but I don't like it as a solution for adding a permanent interface. Shaggy -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
