Le 25/08/2019 à 14:54, Richard Owlett a écrit :
On 08/25/2019 07:36 AM, Pascal Hambourg wrote:
2. What is the proper search term to use for something whose dimensions
would be "megabytes/inode"? {I'll use "blob" for now }
This is just a ratio without any actual object associated. It should
be chosen close to the estimated average file size to avoid running
out of inodes when there are still plenty of free blocks or the other
way around. The file size to account for is the "real" on-disk size,
including the unused space in the last block. In short, it is the size
rounded to the next block size boundary.
Would "logical sector size" be equivalent to "blob"?
Not at all, unless you expect the average file size to be less than a
logical sector size and set the filesystem block size equal to the
logical sector size.
I thinking in terms of "Will all "sectors" associated with a specific
inode be physically adjacent?"
Ideally they should. Otherwise the file is fragmented. But this is
unrelated with the inode ratio (what you call "blob").
How find discussion of
blob size v file fragmentation [cf head seeks in spinning rust]
blob size v wear problems on SSD [unclear how that's handled now]
blob size v parameters such as bs when using dd [lousy example]
AFAIK, the inode ratio does not matter for these topics. The disk
sector sizes and filesystem block sizes matter more.
Is that different than saying {(blob size)==(block size)}?
Or am I totally confused?
I suspect that you are totally confused.
All your question are related to the block size, not the "blob" size
(aka inode ratio). The inode ratio just serves to calculate the initial
inode count (in combination with the filesystem size) when the
filesystem is created. Nothing else.
inode count = filesystem size / inode ratio
