Dear Greg and Andreas,
Thanks for the replies.
I've read about migration in ext4, but never really touched the code
because as I understand there is a lot of conceptual differences in
the inode structure, block allocation and other metadata in general.
I'm stuck to this (2.6.20) kernel, though (as there are other people
working on the machine for quite a while and they are not keen to
upgrade it), and the rest of my work was already done in ext3 anyway.
I will look into the code you pointed out and see if I can get any
clues out of it. Otherwise I shall bother you again. =)
My problem is pretty much what I said: I am probably doing something
wrong, but I have no idea how to commit the changes to an struct
ext3_inode back to disk. Maybe I should actually be modifying
something else, like a struct ext3_inode_info.
As I said, I also tried to modify the datablock of the inode table
directly on the disk (and committing the changes, syncing, remounting,
etc), but maybe because I am marking the inode dirty, the cache gets
written back to disk and overwriting my changes after I do the
alteration.
Cheers,
Felipe
On 19 Oct 2010, at 23:55, Greg Freemyer wrote:
On Tue, Oct 19, 2010 at 5:56 PM, Andreas Dilger <adilger@xxxxxxxxx>
wrote:
On 2010-10-19, at 09:23, Felipe Franciosi wrote:
I am experimenting on a 2.6.20.3-ubuntu1 kernel to prototype and
evaluate different methods for migrating datablocks for a given
inode on the fly.
I have created an ioctl call that implements some verifications
and invokes a function I wrote in balloc.c for such migration.
Are you aware that there already is the ability to do on-the-fly
migration of files in ext4? This was developed quite some time ago
and is in ext4 in newer kernels (not sure of the exact version,
maybe 2.6.32 or so).
I would strongly recommend that you investigate that code, since it
could definitely use some good testing/inspection/enhancement (as
needed). It is in fs/ext4/migrate.c, though I'm not sure where the
user-space tools are located (maybe e2fsprogs?).
Cheers, Andreas
I'm not familiar with that code, I'm curious what it does?
But there is also the EXT4_IOC_MOVE_EXT ioctl which is called by
e4defrag primarily.
The code is in fs/ext4/move_extent.c
The concept is you allocate new blocks in a donor inode. Once you
have that done, then EXT4_IOC_MOVE_EXT will move the data from the
original data blocks to the new ones and replace the old original
blocks with the new donor blocks.
All done on the fly.
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
