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

[Nathan Whitehorn]

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.

I suspect the consensus of people like -arch and -fs will be that the
burn-in time before it is considered sufficiently stable is be
measured in years.

Which is a good reason to have a UI to set it :)
Or maybe when you say "auto" it asks if you want it on or not.

Yes, there should be a UI for sure. Just ENOTIME so far.
-Nathan

[Nathan Whitehorn]

Author: nwhitehorn
Date: Tue Mar 15 13:27:34 2011
New Revision: 219667
URL: http://svn.freebsd.org/changeset/base/219667
Turn on softupdates by default. We need a UI to set filesystem
parameters.
head/usr.sbin/bsdinstall/partedit/gpart_ops.c

This would appear to still be a change from the previous behaviour,
where softupdates were enabled by default for any filesystem except for
the root filesystem.

It is -- and this needs to become settable. Bear in mind, however, that
the default partition layout is also different. If you select the auto
option, only one file system is made, so there are no non-root file systems.

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

[Kirk McKusick]

Date: Fri, 18 Mar 2011 20:50:08 -0500
Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit

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

The requirement that the root run without SU derived from the fact that
you could get out of space errors if you tried to replace files too
quickly (e.g., during installworld). That problem was fixed about 2004.
So there is no reason that root cannot have SU enabled. In particular,
if you are going to default to a single filesystem, then root should
definitely have SU (or SU+J per above) enabled.

Kirk McKusick

[Marius Strobl]

Post by Kirk McKusick

Date: Fri, 18 Mar 2011 20:50:08 -0500
Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit

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

[Doug Barton]

Post by Marius Strobl
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.

+1

I tried enabling SU+J on my /var (after backing up of course) and after
a panic random files were missing entirely. Not the last updates to
those files, the whole file, and many of them had not been written to in
days/weeks/months.

With all due respect to the hard work that went into the code, I would
be very uncomfortable with enabling it by default at this point.


Doug