If this was a guarantee, I would assume that the initial two entries
could be optimized as two inodes.
> > Also, I'm not certain, but I suspect that the reclen vs namelen
> > difference allows the ext2(/3) format to be extended while minimizing
> > breakage to existing code. One day another field might be added to the
> > inode and any assumptions regarding the size of a record length would
> > limit such extensions. (One such field is currently the 'file type',
> > although, the file type does not actually use up any additional bytes)
> Doesn't matter, reclen still makes it a linked list, and we'd still skip
> over 'dead' entries, regardless of content.
If the extra bytes (reclen - namelen) *were* extra bits of file system
information, there would be no safe way of ensuring that the allocation
of a new directory entry didn't 'accidentally' overwrite these bytes.
Exactly how big should you assume reclen *really* is, if reclen
sometimes means the length of the record, and other times means a next
pointer offset?
mark
-- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, CanadaOne ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/