> > The major advantage of doing this, is that we now
> > have an easy way to expand/shrink a filesystem,
> > even when it's up and running. All we need to do
> > to shrink an fs is to have a kernel daemon:
> > mark the to-be-removed volume as such, so blocks won't
> > be allocated under us when we're migrating data
> > walk all inodes on the fs
> > relocate all inodes and blocks off of the to-be-removed volume
>
> Relocating inodes is hard, since there is no cheap way to determine
> which dirents refer to a given inode. Relocating blocks is not much
> easier, since there's no lookup from block to inode either, but at least
> there's only one owner inode for every block.
Relocating inodes is indeed next to impossible on a live FS :-(
but relocating blocks is very easy, you just have to do it on
a per-inode basis instead of on a per-block basis.
It would be a bit like the way try_to_swap_out() scans memory.
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu