| 1 |
On Sun 21 August 2011 21:23:15 Andrea Conti did opine thusly: |
| 2 |
> > Filesystem Inodes IUsed IFree IUse% Mounted on |
| 3 |
> > /dev/mapper/weird-inodetest 1024 1024 0 100% /mnt |
| 4 |
> > |
| 5 |
> > /dev/mapper/weird-inodetest 2048 1024 1024 50% /mnt |
| 6 |
> |
| 7 |
> Then I stand corrected. I guess that the man page for mke2fs saying |
| 8 |
> that the inode count of a filesystem cannot be changed does not |
| 9 |
> take resizing into account. |
| 10 |
|
| 11 |
Correct. A resized fs is technically a re-formatted fs. So to the |
| 12 |
ultra-pedantic the man page is actually still correct. |
| 13 |
|
| 14 |
> I also thought that if resize2fs had the ability to extend the inode |
| 15 |
> table, then it would have options to give the user some degree of |
| 16 |
> control over the process. Apparently that's not the case. |
| 17 |
|
| 18 |
inodes are not dynamic, they are laid down at exact points on the disk |
| 19 |
and the info about their location is in the superblock(s). The |
| 20 |
simplistic explanation is something like this: |
| 21 |
|
| 22 |
You have X number of inodes, spaced Y blocks apart on a disk of size Z |
| 23 |
bytes. A directory listing declares a file is at inode #M therefore |
| 24 |
it's physical position on the disk is guaranteed to be at |
| 25 |
|
| 26 |
M * (block size) |
| 27 |
|
| 28 |
and the filesystem driver can seek directly to that spot. Two things |
| 29 |
are immediately self-evident: |
| 30 |
|
| 31 |
1. Changing the density of inodes is not realistic (unless you want to |
| 32 |
invest the same effort that went into Window's defrag) |
| 33 |
|
| 34 |
2. Fixed inodes are an ancient concept that provoke an "Eh? Say what? |
| 35 |
You still doing that????" response. ReiserFS was developed in part to |
| 36 |
address this and make an |
| 37 |
|
| 38 |
-- |
| 39 |
alan dot mckinnon at gmail dot com |
Archives