svn commit: r219667 - head/usr.sbin/bsdinstall/partedit

[Marius Strobl]

On Sat, Mar 19, 2011 at 05:00:51PM -0700, Kirk McKusick wrote:
> > Date: Fri, 18 Mar 2011 20:50:08 -0500
> > From: Nathan Whitehorn <nwhitehorn at FreeBSD.org>
> > Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
> > To: Gavin Atkinson <gavin at FreeBSD.org>
> > Cc: src-committers at FreeBSD.org, svn-src-all at FreeBSD.org,
> >         svn-src-head at FreeBSD.org
> > 
> > On 03/15/11 12:50, Gavin Atkinson wrote:
> > > On Tue, 2011-03-15 at 12:26 -0500, Nathan Whitehorn wrote:
> > > Hrm, I hadn't realised this was the case.  If this change is intentional
> > > and planned to remain, I guess the various bits of documentation that
> > > say "several partitions good, one bad" should be updated...
> > 
> > It is intended. I think it makes things somewhat easier for the 
> > virtualization case, and I know a lot of people have been running their 
> > systems with "one-big-/" for years. If it is harmful for some reason, 
> > however, it's easy to change.
> > 
> > >>> I wonder if it is time to start enabling SU+J on non-root filesystems
> > >>> now?
> > >> That's certainly something to think about, although I'll defer whether
> > >> that is wise to others. It's a little bit of a pain on the
> > >> implementation side, since you can't turn it on from newfs, but that
> > >> isn't a serious obstacle.
> > > As of r218726, you can now set this from newfs. (-j)
> > 
> > Ah, wonderful. The decision of whether that is a good idea still rests 
> > with others, however :)
> > -nathan
> 
> I believe that we should enable SU+J by default. We should do it now
> so that we can get wider experience with it before 9.0 is released
> (thus letting us revert to SU if uncorrectable problems arise).

I fear it's still a bit premature for enable SU+J by default. Rather
recently I was told about a SU+J filesystems lost after a panic
that happend after snapshotting it (report CC'ed, maybe he can
provide some more details) and I'm pretty sure I've seen the problem
described in PR 149022 also after the potential fix mentioned in its
feedback.

Marius