UFS2 and DragonFly [Re: Fw: setjmp/lonjmp (was: vinum warning)]

[David Rhodus]

On Thu, 3 Feb 2005 23:58:41 -0300, Luiz Otávio Souza
<luiz at xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >    maintain.  In Kirk's case the main problem is a lack of in-code
> >    documentation of the very complex algorithms he uses in softupdates
> >    coupled with his propensity to hack up other parts of the system to
> >    crowbar pieces in (like the background bitmap writing code, the
> > snapshot
> >    code, the major reliance on the precise actual implementation of other
> >    pieces of VFS system in order to be able to assume certain side effects
> >    which are also not documented anywhere in the code, and so forth).
> >
> > -Matt
> 
>  did you have plans to support UFS2 ?

Yes, we will be adding in support for UFS2 or as you may have it,
filesystems which are greater than 1TB in size.

I already have started working on this as several of my machines have
more than an 1TB of disk space.  Disk controllers such as 3Ware
controller cards are making large filesystems more and more prevalent
everyday.  As the 500Gig disk drives come out this quarter I plan on
upgrading the disks in my personal machines which will make the issue
even more pressing.


> 
>  this will simplify the backport (?) of 5.x, 6.x installations to DFBSD.

Yes, it will simplify the process so you don't have to completely blow
everything away and layout a new filesystem.  Though an upgrade from
5.x/6.x even then would still be for experts only as the signal code
is different and binaries from those machines won't run directly.

>  Also, some of features are interesting (ACL mostly).

We will eventually add in some type of ACL support but the earliest
work will start on this will be sometime next year.

>  The snapshots are very cool, but i never get a stable system with that and
>  so, i don't care about it.

No, we will *NOT* be porting over the snapshots code as our journaling
code will be far superior.

-- 
                                            -David
                                            Steven David Rhodus
                                            <drhodus at xxxxxxxxxxx>