On Fri, Nov 02, 2012 at 02:59:29PM -0400, Gary Palmer wrote: > On Fri, Nov 02, 2012 at 07:41:31PM +0100, Mateusz Guzik wrote: > > On Fri, Nov 02, 2012 at 07:30:04PM +0100, Bas Smeelen wrote: > > > On 11/02/2012 07:17 PM, Bas Smeelen wrote: > > > > On 11/02/2012 07:08 PM, Bas Smeelen wrote: > > > >> On 11/02/2012 06:27 PM, Adam Strohl wrote: > > > >>> On 11/3/2012 0:13, Mike Jakubik wrote: > > > >>>> You can disable SU+J after installing, though it would be nice if the > > > >>>> installer gave you a choice. > > > >>> This assumes that you know about this flaw, which most people do not. > > > >>> > > > >>> I didn't until I discovered it by panic-ing a perfectly fine running > > > >>> server. Getting burned by a known bug like this shouldn't be "SOP" > > > >>> for users of FreeBSD. > > > >>> > > > >>> If anything it should be turned off by default, and people can turn it > > > >>> on if they want given the landmine it plants. If they know how to > > > >>> turn it on they're much more likely to be aware of the issue. > > > >>> > > > >>> > > > >>> > > > To sum it up > > > SU+J should be turned off by default because of > > > 1. It does not work with dumping a live system e.g. snapshot > > > 2. it is not recommended for SSD installs > > > 3. "Smart" admins can turn it on if they want > > > > > > root@sys:/usr/src/usr.sbin/bsdinstall/partedit # diff -u gpart_ops.c > > > gpart_ops.cnew > > > --- gpart_ops.c 2012-08-06 01:54:33.000000000 +0200 > > > +++ gpart_ops.cnew 2012-11-02 19:07:45.000000000 +0100 > > > @@ -90,8 +90,8 @@ > > > {"SU", "Softupdates", > > > "Enable softupdates (default)", 1 }, > > > {"SUJ", "Softupdates journaling", > > > - "Enable file system journaling (default - " > > > - "turn off for SSDs)", 1 }, > > > + "Disable file system journaling (default - " > > > + "turn on for adventurish admins)", 0 }, > > > {"TRIM", "Enable SSD TRIM support", > > > "Enable TRIM support, useful on solid-state drives", > > > 0 }, > > > > > > Please comment, then I can file a PR or not > > > > As was noted in my another mail, the kernel will no longer crash when an > > attempt to take a snapshot is made. Also AFAIR SUJ can be disabled > > later. > > > > Given that I prefer the following: > > > > diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c > > b/usr.sbin/bsdinstall/partedit/gpart_ops.c > > index 479365a..80296c2 100644 > > --- a/usr.sbin/bsdinstall/partedit/gpart_ops.c > > +++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c > > @@ -91,7 +91,7 @@ newfs_command(const char *fstype, char *command, int > > use_default) > > "Enable softupdates (default)", 1 }, > > {"SUJ", "Softupdates journaling", > > "Enable file system journaling (default - " > > - "turn off for SSDs)", 1 }, > > + "turn off for SSDs or if you use snapshots)", 1 }, > > {"TRIM", "Enable SSD TRIM support", > > "Enable TRIM support, useful on solid-state drives", > > 0 }, > > > > http://people.freebsd.org/~mjg/patches/suj-snapshot-comment.diff > > How many people realise that snapshots are needed for dump based backups > (and other related features)? >
I thought this is a common knowledge. When you run dump without -L on a live filesystem, it advises you to re-run with -L option. And -L description in the man page clearly states that it uses snapshots. The comment can be updated to mention that snapshots are used by dump with -L. I don't have a strong opinion on this subject, just wanted to correct Adam on his claims regarding panics with snapshots and while here I provided a patch that is more likely to get accepted since it does not change any defaults (and I hoped it would address concerns about admins installing new systems with SUJ unaware that it does not work with snapshots). -- Mateusz Guzik <mjguzik gmail.com> _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"