[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resize start of Ext2?

From: Andrew Clausen
Subject: Re: Resize start of Ext2?
Date: Wed, 25 Sep 2002 06:19:15 +1000
User-agent: Mutt/1.4i

On Tue, Sep 24, 2002 at 07:48:23PM +0100, CS Miller wrote:
> Is there any reason for this? From my (half-forgotten) understanding of the 
> classic UNIX filesystem, this should be a fairly easy task.


> Assuming suffecent free space in the partion, all you should have to do
> is recreate the partion header, free and bad block maps, then create a new 
> list of inodes (pointing to the existing file blocks), and the directory 
> hierachy.

Right.  You also have to modify all indirect blocks, since their "pointers"
are pointing in a different address space (they are relative to the
start of the partition, which just changed).

Likewise, inodes will be renumbered, so you need to update the directory

This is all a lot slower than the current ext2 resizer... resizing
the start is a fundamentally slower operation... unless the file
system had support for negative addressing.  (i.e. having "block 0"
in the middle of the file system)

> Moving downwards is easier, as moving upwards will involve shuffling existing 
> files out of the way. Making the minimum move atleast the size of the control 
> blocks will make the task a lot easier (the existing control blocks can be 
> kept until the ones are ready), without that much hassle for the end user.

You always have to shuffle files, to allocate new inode tables, etc.
You don't want to clobber the old inode tables while you're resizing.

> I've had a few googles for the EXT2 layout, but haven't found that much 
> explaining it in detail, so I might be missing something. A few pages 
> suggested that EXT2 is sub-divided into areas, each of which has the classic 
> UNIX structure, but I can't see how these would be linked together, or large 
> files can span more than one area. Apart from RFTM, is there any good 
> resources for this?


Inodes can have blocks from different block groups, although the block
allocator will try to avoid this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]