Thor Lancelot Simon <tls@rek.tjls.com> writes:
> > 1) Eliminate the remaining file size limits. As it stands, you can't
> > actually have an FFS file of 2^63rd size, although the system calls
> > are all fine.
> > 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.
> > 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.
> 
> Speaking of "old goo" -- I'd like to propose rotational position optimization
> as "old goo" that is not useful on any disks manufactured in almost 10 years,
> costs CPU, and needlessly complicates the data structures.

Agreed.

We could also get rid of the HUGE number of unneeded extra superblock
copies. I mean, ten backups is probably enough -- a couple hundred on
a huge disk is past overkill.

> In fact, if we're changing the filesystem enough to require a magic number
> change, I'd think *all* the stuff that tries to understand the disk layout
> (aside from "close by block number") could go.  It just can't describe
> modern disks, for which you often can't get the real data anyway.

Seems reasonable.

I agree with the rest of what you say, too.

> Also, it'd be nice to support more fragmentation than the current 1/8
> limit, so we could use larger blocks without wasting so much space
> (and avoid the need to cluster in many cases -- though the current
> limitation of only being able to cluster to MAXPHYS, which is a lot smaller
> than the actual maximum size transfer you could get across the buses to the
> disk on many buses/controllers/disks on many ports, is kinda a separate
> though related lose, and this wouldn't help avoid it).
> 
> Basically, if we're going to introduce a "new FFS", maybe it'd be better
> to do so for more than one fairly small (if useful and cool) change.  I
> don't think we should bump the magic number for just this, not in a
> public release at least.