Re: [agc%pkgsrc.org@localhost: Re: Google SoC Proposal Ideas]

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> I don't think that having to unmount a file system, resize it, and
>>> mount it again is viable these days - we need file systems that can
>>> grow and shrink whilst still mounted.
>> Are you saying that the resizer utility needs to eventually to be
>> able to resize the filesystem while it is 'live' or that the
>> filesystem itself needs to first support this?
> I think future file systems design and implementation is beyond the
> scope of the file system resizer project -

Perhaps, but I can't see any reason FFS couldn't be resized live, given
a few hooks into its internals.  It'd be slower, of course, but
definitely doable.

Do we have any interface that would allow this, something a la ioctl()
but that takes a filesystem mount point and speaks to the filesystem
implementation rather than taking a file descriptor and speaking to the
object backing it?  (Exactly how the "filesystem mount point" is named
is irrelevant to the fundamental desire here.  Maybe a string, maybe a
file descriptor, maybe something else - it's mostly irrelevant.  Hmm,
this sounds like a good use case for a new socket type, whose connect()
addresses are filesystem mount point strings and whose "remote"
endpoints are the underlying filesystem implementations.  But this is
veering off of tech-userlevel's subject.)

> and I'd really like to see us having the ability to resize FFSv2 file
> systems well.

If FFSv2 is as similar to FFSv1 as the hints I've seen make me think,
all it would take to get an offline resizer would be someone who knows
v2 updating resize_ffs.  (That someone is not me, at least not yet; I
haven't looked at v2 internals at all.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B