diff options
author | jhb <jhb@FreeBSD.org> | 2008-09-16 19:06:44 +0000 |
---|---|---|
committer | jhb <jhb@FreeBSD.org> | 2008-09-16 19:06:44 +0000 |
commit | 281938f04d3e2b1b91827e77d5ee4e74471b6a31 (patch) | |
tree | dcb0297e7f186a947d0546f2999779af9a1aeeb9 /libexec/smrsh | |
parent | f4b6175ac36dd9b7f304e8379e2b49bed317fb3e (diff) | |
download | FreeBSD-src-281938f04d3e2b1b91827e77d5ee4e74471b6a31.zip FreeBSD-src-281938f04d3e2b1b91827e77d5ee4e74471b6a31.tar.gz |
Retire the 'i_reclen' field from the in-memory i-node. Previously,
during a DELETE lookup operation, lookup would cache the length of the
directory entry to be deleted in 'i_reclen'. Later, the actual VOP to
remove the directory entry (ufs_remove, ufs_rename, etc.) would call
ufs_dirremove() which extended the length of the previous directory
entry to "remove" the deleted entry.
However, we always read the entire block containing the directory
entry when doing the removal, so we always have the directory entry to
be deleted in-memory when doing the update to the directory block.
Also, we already have to figure out where the directory entry that is
being removed is in the block so that we can pass the component name
to the dirhash code to update the dirhash. So, instead of passing
'i_reclen' from ufs_lookup() to the ufs_dirremove() routine, just read
the 'd_reclen' field directly out of the entry being removed when
updating the length of the previous entry in the block.
This avoids a cosmetic issue of writing to 'i_reclen' while holding a
shared vnode lock. It also slightly reduces the amount of side-band
data passed from ufs_lookup() to operations updating a directory via
the directory's i-node.
Reviewed by: jeff
Diffstat (limited to 'libexec/smrsh')
0 files changed, 0 insertions, 0 deletions