by Brian Fields

Inode maps would point to inode logs (except in the case of Keep-One),
instead of simply inodes. The version numbers in the segment summary
block could have the same semantic as they do now, i.e. an inode log
would have have an LFS version associated with it and internally have
Elephant versions for each inode in the log.

Segment cleaning would involve another step: Besides the normal LFS
cleaning, inode logs would have to be managed according to the
appropriate Elephant policy. This could be accomplished by placing the
"temperature", "type", "policy", and "policyGroup" fields of
Elephant's imap into the inode map of the LFS scheme. When segment
cleaning looks at this map, the inode log will be examined for
Elephant-style cleaning according to the temperature and policy. The
Elephant-style cleaning would simply identify more space to be freed;
LFS could then coalesce the free space.

Directories would have to be constructed as in the Elephant system:
starting out with a single inode but transitioning to an inode file as
the number of (especially deleted) names increases.

Segment cleaning policy could be tailored a bit more by grouping
together current versions when segments are written out. This would
optimize the common case of reading current versions. The older
versions of policies such as 'Keep-All' are likely to be very
rarely accessed and stable. They could be stored compactly in
segments that will rarely need to be cleaned. Other policies, such
as 'Keep Safe' will require cleaning of older versions quite
regularly and placement could be optimized for this case.