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

Re: dynamic inode allocation



On Mon, Sep 1, 2008 at 2:37 PM, Theodore Tso <tytso mit edu> wrote:
> On Mon, Sep 01, 2008 at 01:18:31PM -0400, Mag Gam wrote:
>> This maybe a newbie question but how come other file systems such as
>> ReiserFS and Veritas' Vxfs dynamically allocate inodes and filesystems
>> such as ext2/ext3 and JFS we need to allocate them when creating the
>> filesystem? Is there a performance or maintenance gain when pre
>> allocating?
>
> Having a static inode table is definitely much simpler than a dynamic
> inode table, and that's why ext2 originally used a static inode
> allocation system.  Ext2 drew much of its initial design inspiration
> from the BSD Fast Filesystem, and it (along with most traditional Unix
> filesystems) used a static inode table.
>
> One of the advantages of having a static inode table is you can always
> reliably find it.  With a dynamic inode table, it can often be much
> more difficult to find it in the face of filesystem corruption, caused
> by either hardware or software failure.  For example, with Reiserfs,
> the inodes are stored in a B-Tree.  If the root node, or a relatively
> high-level node of the B-tree is lost, the only way to recover all of
> the inodes is by looking at each block, and trying to determine if it
> "looks" like part of the filesystem B-tree or not.  This is what the
> reiserfs's fsck program will do if the filesystem is sufficiently
> damaged.  Unfortuntaely, this means that if you store reiserfs
> filesystem image (for example, for use by vmware, or qemu, or kvm, or
> xen) in a reiserfs filesystem, and the filesystem gets damaged, the
> recovery procedure will take every single block that looks like it
> could have been part Reiserfs B-tree, and stich them together into a
> new-btree.  The result, if you have Reiserfs filesystem images is
> those blocks will get treated as if they were part of the containing
> filesystem, and the result is not pretty.
>
> These problems can be solved (although they were not for Reiserfs),
> but it means a lot more complexity.
>
>                                                        - Ted
>

Ted,

Thanks for the explanation and dumb-ing it down for me :-)

So, if a reiserFs filesystem is damaged and it naturally do a fsck.
The fsck basically recreated the b-tree by scanning from 1 to end of
the filesystem?


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