Re: looking for open tasks

On 2007-02-28 at 17:50:33 [+0100], Axel Dörfler <[email protected]> 
wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > The implementation of the required interface is missing for BFS
> > (which would
> > be the FS in question), but the code to initialize a partition is
> > already all
> > there. So that's a minor task. Interesting would be resizing, though,
> > at
> > least increasing the size while not mounted. Don't know how much work
> > that
> > would be; Axel can tell, I suppose.
> 
> Resizing/shrinking BFS is lots of work. Especially if you wanted to do
> it while being mounted :-)

That's while I suggested "while not mounted". :-)

> Furthermore, when changing the size of a BFS volume, you couldn't keep
> all inodes constant which means some stored entry_refs might become
> invalid.

If you actually store entry_refs on disk it's your own fault. One simply 
doesn't do that, at least not when the info can't be reconstructed another 
way. Live operations are tricky though, since even entry_ref in memory become 
invalid. That's why I wouldn't support "live" operations that might change 
node IDs for the time being.

> Anyway, the first thing one would have to do is to add a way to move a
> file and its contents to some other location. When you've done that,
> all other tasks will be much simpler.
> Resizing a volume would also be simplified if you have some constraints
> on the new size, ie. you could not allow to change the size of the
> allocation groups; if you only change the number of them, the whole
> thing would be much easier to do.

What affects the size of allocation groups?

CU, Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV