I'm worried about rushing in a feature that seems to have no benefit to
the release.  (Or, at least, it has a publically unknown benefit.)

Perhaps the benefit is merely unknown to me. So, "How will this benefit
the 1.4 release??".

> 2) Expand time in inodes to 64 bits of seconds. Sure, we have 39 years 
> to do it but I see no reason not to do it now given the relative
> expense of writing an inode to disk vs. the expense of the extra
> couple of operations.

Nice point, Perry. This is a really good example of why public comment
for such a major thing as an FFS respin is helpful.

The propaganda value of this one feature would be tremendous.

> 3) Eliminate endianness of FFSes -- this is more controversial. Right
> now, we have bi-endian support, but it would be cool not to need it.
> 4) GC old goo like the old uid/gid support.

I can think of more things: increasing NDADDR, for one. It's only 12 right
now. Perhaps there is no point in this one idea, but that's the reason for
the open development review.

This feature is obviously important (presumably for HSM) to a project.
Perhaps with wider review it could be generalized and made more useful.

	Ross.Harvey@Computer.Org