[mythtv-users] Changing filesystems?

[Jeff]

Quoting Steve Bower <sbower at cisco.com>:

> >>>>> "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!  :-)
> 

Seeing as how I started this...my original post was flawed as pointed out by 
Steve, I said used a lot of inodes when I really meant block pointers (was just 
typing away).  Anyway, thanks everyone for the info, my greatest fears were 
realized <g> and I'll probably have to find room on another box to copy off my 
70G worth of recordings and create the new file system.  Was hoping to skate by 
and was looking for an easy way to change fs to no avail.

Jeff