It's a huge win for CPU overhead in the filesystem, especially
when we start talking about increasing the size of m_links
field and possibly going 64-bit inode numbers.
Talking about going to 64-bit inode numbers, how would we deal
with the change in stat(2)?
By making some sort of incompatible change to stat(2). This has
been discussed from time-to-time. It's another change that I
would have liked to have seen (at least for the stat routines)
in 6.0, but right now I suspect it will not happen until 7.0.
We can't go making incremental incompatibilities to the filesystem
without a good deal of planning. This is the type of thing that
would go into a 'UFS3'. I have some long-term plans here, but I
need to get the initial proof-of-concept journalling working before
I start to seriously consider what else would be in UFS3.