[Tux3] symlink, truncate, unlink, link, and some bug fixes
OGAWA Hirofumi
hirofumi at mail.parknet.co.jp
Sun Dec 7 08:13:39 PST 2008
Daniel Phillips <phillips at phunq.net> writes:
> It all looks beautiful, and as usual, it builds cleanly, passes all the
> tests, boots up and mounts without problems. I did not test the new
> functionality yet. Pushed to public.
Thanks
> One idea on the links count attribute: as a later optimization, how
> about we store it only if it is not equal to one? That is the majority
> of cases. Saving the 6 bytes of link count attribute for most files
> will reduce our average inode size by 12% or so. I previously
> suggested we interpret a missing links attribute as zero, but that is a
> rare case (orphan and internal inodes). We should just store the
> attribute then.
Sounds good. I think we can use that rule for all inode attributes.
Store attribute only if it is not initial value.
For internal inodes, we can use 1, or 2 if dir (just use initial value).
i_mode, i_uid, i_gid are 0 as initial value, so internal inodes don't
need MODE_OWNER_ATTR too. Well, finally, I guess the internal inode will
have only DATA_BTREE_ATTR.
Maybe, the issue would be overhead. I think this optimization means it
may change total data size in ileaf to store. So, it may become cause
of changing the btree depth (I'm not sure this cost is cheap or not).
> Link count for a directory is always 2 + number of subdirectories.
> What about storing one less than the directory link count, so that
> the stored link count for a directory with no children is one, which
> is most directories?
FWIW, as just FYI, The following is fs/isofs/inode.c:1262
if (de->flags[-high_sierra] & 2) {
inode->i_mode = sbi->s_dmode | S_IFDIR;
inode->i_nlink = 1; /*
* Set to 1. We know there are 2, but
* the find utility tries to optimize
* if it is 2, and it screws up. It is
* easier to give 1 which tells find to
* do it the hard way.
*/
It seems to use 1 for find command.
Well, I think we can do - if is_dir && inode->i_link != 2, it is stored.
> Then we also would not have to store the size attribute for a
> directory.
This is about phtree? Well, anyway, we would have to cleanup present
flags, because we are using CTIME_SIZE_BIT (ctime + size).
--
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>
_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
More information about the Tux3
mailing list