[patch] Re: SU+J on 9.1-RC2 ISO

[Bas Smeelen]

On 11/02/2012 07:41 PM, 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 at 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
>

Hi Mateusz
I can see some benefits of having journaled soft updates and I 
understand your preference.
Though the last 10 years I have not had the inconvenience of having to 
deal with long fsck' s or bgfsck' s on servers or workstation installs, 
so I think this should not be default on new installs.
Since there are more SSD installs nowadays, it might be a good option to 
turn soft updates journaling off by default.
Can you explain the benefits of having journaled soft updates turned on?
There are also a lot of back-up service providers who use the snapshot 
functionality to be able to host a lot of back-ups, though they might be 
using zfs for this now I would guess.
Kind regards
Bas





This e-mail message, including any attachment(s), is intended solely for the addressee or addressees. Any views or opinions presented herein are solely those of the author and do not necessarily represent those of OSE.

If you are not the intended recipient of this communication please return this e-mail message and the attachment(s) to the sender and delete and destroy all copies.