Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Oct 2017 15:25:13 -0700
From:      Kirk McKusick <mckusick@mckusick.com>
To:        Mark Johnston <markj@FreeBSD.org>
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: softdep as a mount(8) option
Message-ID:  <201710282225.v9SMPDCZ074228@chez.mckusick.com>
In-Reply-To: <20171027153859.GC2385@raichu>

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 27 Oct 2017 11:39:00 -0400
> From: Mark Johnston <markj@FreeBSD.org>
> To: freebsd-fs@FreeBSD.org
> Subject: softdep as a mount(8) option
> 
> Hi,
> 
> I'd like to finally enable the use of SU (not SU+J) on some small UFS
> filesystems. The fact that SU is enabled using a flag in the superblock
> poses a problem for me, however: the systems containing these
> filesystems may at any time be repurposed to run a kernel that supports
> SU but contains bugs[*] that render it unusable. I therefore can't
> persistently enable SU in these systems.
> 
> I'm wondering if it would be possible to enable SU using a mount
> option rather than with a persistent flag. fsck_ffs conditionalizes some
> of its logic on whether SU is configured - is this necessary for
> correctness? That is, if I run fsck on an unclean filesystem that had
> been mounted with SU, and fsck runs as though SU hadn't been configured,
> what problems might arise?
> 
> [*] These bugs are a result of local modifications and aren't in
> FreeBSD.

While it is safe and possible to add soft-updates (but not journalled
soft updates) as a mount option, it means that fsck will not know that
soft updates were in use, so it will always run in full (slow) mode at
boot time. This is why I have not added it as an option.

	Kirk McKusick



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201710282225.v9SMPDCZ074228>