>> Now that I think about it... Relocating inodes isn't that
>> hard either. You just have to walk the file tree and
>> relocate the inode once you've found all links to it.
>
> Walking the file tree while other operations may be changing
> the file tree out from under you is hard....
Repeat until the job is done.
> Probably our best hope of success is to have a combination user-level
> and kernel-level scheme where the actual filesystem scan is done by the
> user-level code, but you would need the kernel-level code to intercept
> certain operations during the relocation operation.
Yes, this is what NT (and VMS?) use. I just outlined the whole LVM
add/remove ability in comp.os.linux.development.system. I'll try to
repeat it for those that don't read usenet news:
1. Add filesystem-dependent code to swap disk blocks. This code can
return an error code if the caller tries to move inodes and other
metadata with predefined locations. Maybe require that one block
is free and one block is in a file. Also add a way to swap inodes
and anything else that must be moved. These functions must go in
the kernel so that they can operate on live filesystems.
2. Create a user-space defrag program that uses the kernel calls to
actually move the data. Note that bugs in this program are harmless,
which is really interesting for a defrag program!
3. Have ext2 (or a lower layer) know about sparse block devices or
find some other way to disable a block group. User-space must be
able to tell ext2 to stop allocating things in a block group.
4. Put it all together: User-space disables the block group, moves
files out of it, updates filesystem size info, and marks the
space free in the logical volume.
Steps 1 and 3 look hard, but I don't think there is anything that
would be really impossible to do. The worst part is that bugs in
steps 1 and 3 would tend to scramble your disk. It takes guts to
do serious filesystem hacking -- maybe an NFS root would help.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu