Re: VFS 64-bit clean

Matti Aarnio (matti.aarnio@tele.fi)
Fri, 27 Feb 1998 14:54:26 +0200 (EET)


> On Thu, 26 Feb 1998, Stephen C. Tweedie wrote:
>
> > 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.
>
> 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.

You must mean RENUMBERING inodes. If you move around
the meta-data blocks containing i-nodes, you don't
need to renumber referenced i-nodes, just be able to
find those i-nodes in their new locations.

> There aren't that many files with multiple links, so
> you can easily remember them. And as for directories,
> since we walk the _file tree_, most directories that
> belong together are found more or less at the same
> time...

Sure, presuming you created them to their full
extent at time T0. In practice you keep adding
files to directories, and directory files will
become very discontiguous as time progresses.

> I reckon that we'll need about 30MB of RAM when doing
> a relocation on a 20GB filesystem. (just some wild
> guess, but I can hardly imagine we need more).

It depends, mounted or unmounted filesystem ?
(I would love to be able to do it to a mounted
system, although perhaps slowly, but still be
able to do it with integrity on running system.
If VMS can do it, why can't Linux do it ?)

> Rik.
> | my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |

/Matti Aarnio <matti.aarnio@tele.fi>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu