Re: Bytes Per Inode
I'm pretty sure that this parameter doesn't affect alignment, nor is it really about the number of bytes consumed by inodes; rather, it's about how many inodes are created on the filesystem. I think it's referring to the -i option to mke2fs, which is described in its man page:
Originally Posted by
mke2fs man page
-i bytes-per-inode
Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value generally shouldn't be smaller than the blocksize of the filesystem, since in that case more inodes would be made than can ever be used. Be warned that it is not possible to expand the number of inodes on a filesystem after it is created, so be careful deciding the correct value for this parameter.
To further understand this, know that an inode is a filesystem data structure that stores information on a file. Every file needs one inode. The ext2/3/4fs family pre-allocates inodes, which means that every ext2/3/4 filesystem has a fixed number of files it can support, defined at the moment the filesystem is created. (Some filesystems, such as ReiserFS, allocate inodes dynamically, so you don't need to make such decisions at the start.)
The "news" setting is named for Usenet news servers, which tend to accumulate huge numbers of extremely small files; this setting allocates lots of inodes to support the large number of files. The "standard" setting is good for general-purpose systems; it allocates fewer inodes, but still plenty for most uses. The "largefile" and "largefile4" settings are good for systems that store very large files (such as a partition for holding MythTV recordings, which are usually gigabytes in size); these allocate fewer inodes, but enough to store all the multi-gigabyte files you could cram onto the disk.
If you select an improper value, the consequences will vary with what you choose. If you select the "news" setting and then store big multimedia files, you'll have tied up too much of your disk space in inodes, so your disk space will be wasted. If you select the "largefile4" setting and then store lots of little ~2 KiB files, you'll run out of inodes and be unable to store more files on the disk despite having lots of free space available.
FWIW, you can view the number of inodes used and available with "df -i", as in:
Code:
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda8 1222992 292410 930582 24% /
/dev/sda5 97344 223 97121 1% /boot
/dev/sda4 4294967295 3015 4294964280 1% /other/shared
/dev/sda1 0 0 0 - /boot/efi
/dev/sda10 2297456 2772 2294684 1% /home
This was taken on a fairly stock Ubuntu 11.04 installation (upgraded from 10.10). I've cut several filesystems from this example for clarity. The /boot/efi partition is FAT, which doesn't use inodes per se, so the values are reported as 0. (You'd see something similar for ReiserFS.) The /boot partition is a small ext2 filesystem, root (/) is ext4fs and holds the bulk of the installation (6.1 GiB used out of 19 GiB). /other/shared is an HFS+ partition that's barely used right now, and /home is an ext4 filesystem that's also mostly empty at the moment. I didn't tweak the inode settings for any of these filesystems; they're all set at default values.
Although this has nothing to do with the 4 KiB alignment required for a WD20EARS drive, you should definitely pay attention to that issue. I wrote this article about it a while ago. The short advice is to use "fdisk -lu", "parted /dev/sd{whatever} unit s print", "gdisk -l /dev/sd{whatever}", or some other command or tool to view the start sector of every partition. Ensure that the start sector number is divisible by 8. If it's not, delete the partition and start over again, using whatever options your favored partitioning tool provides to ensure the start sector number is divisible by 8. (The end sector number is irrelevant. So is the start value of your extended partition, if you've got one.) The good news is that all the major Linux partitioning tools have switched to creating partitions that begin on 1 MiB (2048-sector) boundaries by default, and since 2048 is divisible by 8, you'll probably do fine if you use a recent tool and its defaults. The bad news is that Linux partitioning tools were slow to make this change (Microsoft began doing this with Vista), so a lot of older tools are still out there that will misalign your partitions if you don't watch over them very carefully.
If I've suggested a solution to a problem and you're not the original poster, do not try my solution! Problems can seem similar but be different, and a good solution to one problem can make another worse. Post a new thread with your problem details.
Bookmarks