[mythtv-users] Changing filesystems?

[Steve Bower]

>>>>> "Greg" == Blues Guy <bluesguy_1 at yahoo.com> writes:

Greg> Ok, I promise I'm not going to make a habit out of replying to
Greg> myself, but I wanted to clear up something Steve said in the post
Greg> above me, because it's misleading and I couldn't let it slide...

Likewise!  :-)

Greg> He says, "one file uses exactly one inode, no matter how big it
Greg> is.", which isn't true for EXT3.  This is *mostly* true for a
Greg> filesystem like XFS, that uses dynamic inode allocations and a
Greg> btree free list, but EXT3 *DOES* use inodes per block size,
Greg> dictated by the args when you create the filesystem; thus the
Greg> reason you really want to use the "-T largefile4" option when you
Greg> create it.  This reduces the inode count on the disk, and causes
Greg> less disk thrashing and I/O problems when you delete or create
Greg> large files. (e.g. 2GB+)

Greg, when you say "EXT3 *DOES* use inodes per block size", you're
really referring to the filesystem creation process -- it *creates* so
many inodes per block size, and that's all the inodes you'll ever have
in that filesystem.

When I say "one file uses exactly one inode, no matter how big it is",
I'm referring to operational activities on individual files within the
filesystem, _after_ the filesystem has been created and mounted.

Using the "-T largefile*" option does reduce the number of inodes that
are created when you build the filesystem, allowing more of the disk
space to be used for actual file data, rather than storing the inodes
themselves.

However, when you create a file (NOT a filesystem) and write data to it,
that file is defined by exactly one inode.  Every ext2/3 architecture
document states this.

As the file grows, more and more data blocks are allocated to it; as the
blocks are allocated, they are marked as "in use" in the block bitmaps.

No additional inodes are allocated to a single file as it grows -- all
of the data block pointers exist in the inode, progressing to indirect
blocks (data blocks that contain pointers to other datablocks),
double-indirect and triple-indirect blocks.

If a file did get allocated more inodes as it got bigger, how would
creating a filesystem with fewer inodes help?  Wouldn't you run out of
inodes even with relatively few large files?

Anyways, when a file gets deleted, all of the data blocks that had been
allocated to it must be marked as free.  This occurs in the block-group
block bitmaps (not in the data blocks themselves), and reading/writing
the bitmaps across all of the block groups is what I believe makes the
deletion process take longer for larger files.

Greg> FYI - The -T argument effectively sets the bytes/inode ratio as
Greg> you would with the -i argument...

Yes.

Greg> On the other hand, XFS is a magic in and of itself, and that's a
Greg> story for some other time (because I don't use it...) :-)

Agreed!  :-)

  Steve.

P.S. We can discuss this off-list if you like, and report back after we
come to an agreement!  :-)