On Thu, May 27, 2010 at 8:47 AM, John Baldwin <j...@freebsd.org> wrote:
> On Thursday 27 May 2010 10:13:38 am Marcelo/Porks wrote:
>> On Thu, May 27, 2010 at 10:33 AM, John Baldwin <j...@freebsd.org> wrote:
>> > On Wednesday 26 May 2010 7:56:24 pm Garrett Cooper wrote:
>> >> On Wed, May 26, 2010 at 3:52 PM, Marcelo/Porks <marceloro...@gmail.com>
> wrote:
>> >> >
>> >> > Hi guys. I'm not sure if I could call this a problem but I can disable
>> >> > SU when SUJ is enabled, so SUJ will remain enabled and SU will be
>> >> > disabled.
>> >> >
>> >> > #tunefs -j enable /dev/device
>> >> > #tunefs -n disable /dev/device
>> >> >
>> >> > I did a patch for sbin/tunefs/tunefs.c that disable SUJ when the user
>> >> > disable SU. Maybe this will be useful for some of you.
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> > Index: sbin/tunefs/tunefs.c
>> >> > ===================================================================
>> >> > --- sbin/tunefs/tunefs.c (revision 208580)
>> >> > +++ sbin/tunefs/tunefs.c (working copy)
>> >> > @@ -460,6 +460,14 @@
>> >> > if ((~sblock.fs_flags & FS_DOSOFTDEP) ==
>> > FS_DOSOFTDEP)
>> >> > warnx("%s remains unchanged as
> disabled",
>> > name);
>> >> > else {
>> >> > + /* also disable SUJ */
>> >> > + if ((sblock.fs_flags & FS_SUJ) ==
> FS_SUJ)
>> > {
>> >> > + warnx("soft updates journaling
>> >> > will be disabled too");
>> >> > + journal_clear();
>> >> > + sblock.fs_flags &= ~FS_SUJ;
>> >> > + sblock.fs_sujfree = 0;
>> >> > + warnx("remove .sujournal to
>> >> > reclaim space");
>> >> > + }
>> >> > sblock.fs_flags &= ~FS_DOSOFTDEP;
>> >> > warnx("%s cleared", name);
>> >> > }
>> >>
>> > I think that attempting to disable SU if SUJ
>> > is enabled should just fail with an error message. The sysadmin can then
>> > choose to disable both SUJ and SU if desired.
>>
>> If SU is disabled and One tries to enable SUJ then SU will be
>> automatically enabled.
>> So Why not automatically disable SUJ when One tries to disable SU?
>
> I'm probably not a big fan of either really. :) For something as rarely done
> as tunefs I would prefer to err on the side of caution and require the admin
> to explicitly specify everything.
Yeah... I suppose that makes more functional sense.
-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
