Re: looking for open tasks

"François Revol" <[email protected]> Wed, 28 Feb 2007 22:26:49 +0100 CET
Newsgroups gmane.os.openbeos.kernel.devel
Message-ID <951262175-BeMail@laptop>
> > 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". :-)

ZFS ? :P

> > 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.

Not sure but I think several system and app settings files include 
entry_refs...
specially replicants that need to get an entry_ref to themselves on 
rehydratation to find resources (at least some I saw do this, last of 
mine actually hack around area_for() and get_next_image_info() to find 
the path of the image for a piece of their own code).

> > 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.

Defrag ? :)

> > 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?

IIRC they are sized depending on the partition, with min and max size 
bound by factors like inode size and allocation bitmap size vs possible 
block sizes...

But I guess as long as you can add or remove (empty) allocation groups 
without having to resize them it should be not too hard. That means 
supporting this way of resizing will not allow for arbitrary resizing 
(no you can't change from 10MB to 10TB! :p)

François.

-------------------------------------------------------------------------
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