Typically on most filesystems, the inode number of the root directory of the filesystem is 2, 0 being unused and 1 historically once invisible and used for bad blocks (no longer done, but kept reserved so as not to invalidate assumptions implicit in ufsdump tapes). However, my observation seems to be (at least back at snv_97), the inode number of ZFS filesystem root directories (including at the top level of a spool) is 3, not 2. If there''s any POSIX/SUS requirement for the traditional number 2, I haven''t found it. So maybe there''s no reason founded in official standards for keeping it the same. But there are bound to be programs that make what was with other filesystems a safe assumption. Perhaps a warning is in order, if there isn''t already one. Is there some _reason_ why the inode number of filesystem root directories in ZFS is 3 rather than 2? -- This message posted from opensolaris.org
>Typically on most filesystems, the inode number of the root >directory of the filesystem is 2, 0 being unused and 1 historically >once invisible and used for bad blocks (no longer done, but kept >reserved so as not to invalidate assumptions implicit in ufsdump tapes). > >However, my observation seems to be (at least back at snv_97), the >inode number of ZFS filesystem root directories (including at the >top level of a spool) is 3, not 2.Buggy files may have all types bad assumptions; this problem isn''t new: the root filesystem of a zone is typically in a simple directory of a filesystem with ufs. I seem to remember that flexlm wanted that the root was an actual root directory (so you can run only one copy). They didn''t realize that faking the hostid is just too simple .... Casper
"Richard L. Hamilton" <rlhamil at smart.net> wrote:> Typically on most filesystems, the inode number of the root > directory of the filesystem is 2, 0 being unused and 1 historically > once invisible and used for bad blocks (no longer done, but kept > reserved so as not to invalidate assumptions implicit in ufsdump tapes). > > However, my observation seems to be (at least back at snv_97), the > inode number of ZFS filesystem root directories (including at the > top level of a spool) is 3, not 2.This was traditionally the lost+found inode number.> If there''s any POSIX/SUS requirement for the traditional number 2, > I haven''t found it. So maybe there''s no reason founded in official > standards for keeping it the same. But there are bound to be programs > that make what was with other filesystems a safe assumption.POSIX only requires that ino(1) == ino(..) if you have a root directory. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Richard L. Hamilton wrote: Typically on most filesystems, the inode number of the root directory of the filesystem is 2, 0 being unused and 1 historically once invisible and used for bad blocks (no longer done, but kept reserved so as not to invalidate assumptions implicit in ufsdump tapes). However, my observation seems to be (at least back at snv_97), the inode number of ZFS filesystem root directories (including at the top level of a spool) is 3, not 2. If there''s any POSIX/SUS requirement for the traditional number 2, I haven''t found it. So maybe there''s no reason founded in official standards for keeping it the same. But there are bound to be programs that make what was with other filesystems a safe assumption. Perhaps a warning is in order, if there isn''t already one. Is there some _reason_ why the inode number of filesystem root directories in ZFS is 3 rather than 2? If you look at zfs_create_fs(), you will see the first 3 items created are: Create zap object used for SA attribute registration Create a delete queue. Create root znode. Hence, inode 3. -- Andrew Gabriel _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss