igug@ingr.com (Igug Moderator) (05/26/89)
Would someone clarify something for me? Over a period of time I understand that a directory file will continue to grow as new inode slots are added. When the files in a directory get deleted and the inode is nulled out, the size of the directory yet remains the same. Fine, now when I begin to add files again are the old slots, that were nulled, reused in the same sequence? Also, will I encounter 'file system indirection' only when I access a file that has its inode in the 321st slot? Also, can I look at a directory file with fsdb and can anyone recommend a good book that covers use of fsdb. Thanks
linwood@b11.ingr.com (Linwood Varney) (05/31/89)
In article <5434@ingr.com> igug@ingr.com (Igug Moderator) writes: >Over a period of time I understand that a directory file will continue >to grow as new inode slots are added. When the files in a directory >get deleted and the inode is nulled out, the size of the directory yet >remains the same. Fine, now when I begin to add files again are the >old slots, that were nulled, reused in the same sequence? When a file is created, the first nulled out entry is used. >Also, will I >encounter 'file system indirection' only when I access a file that has >its inode in the 321st slot? What do you mean by file system indirection. the first 64 directory entries are stored in 1 logical block (1K) of data on the disk. the next 64 in another and so on. After 10 logical blocks are used, a file system indirect block has to be read to get to the next 512 (1K) blocks. This is the struct for System V 1K File Systems. Fast File Systems look much different. >Also, can I look at a directory file with fsdb and can anyone recommend >a good book that covers use of fsdb. The easiest way to look at directories is with od -c first 2 bytes, inode number, next 14 bytes, file name. 16 bytes per record. - linwood