howto: enabling journaling on softupdates
ohartman at zedat.fu-berlin.de
Thu Sep 1 16:06:23 UTC 2011
On 09/01/11 13:26, Ian FREISLICH wrote:
> Niclas Zeising wrote:
>> Can you please detail a little more the steps you took to enable SU+J
>> and your experience with it? It sounds like a good start for a howto or
>> an inclusion in the handbook.
> It's really simple...
> You need a kernel compiled with
> options SOFTUPDATES # Enable FFS soft updates support
> In single-user mode or unmounted filesystems:
> tunefs -j enable<device>
Yes, it is really "THAT SIMPLE". But after enabling SU+J, I ran a "fsck"
on the filesystem in
question and I was asked wether I want to enable journaling and I had to
n for NO or y for YES. One can avoid this by issuing "fsck -y". This is
enabling SU+J. If your're about to enable a bunch of filesystems, boot
box in in singleuser,
then type "tunefs -j enable /dev/gpt/blabla or whatever your partition
in question is
located at or simply the last mountpoint referred to in /etc/fstab.After
having done this, issuing
the command "fsck -y" performs a filsesystem check and enables SU+J. It
is assumed, that suoftupdates are
configured in the kernel via "options SOFTUPDATES", which is at least
default in FreeBSD's
GENERIC kernel config file for FreeBSD 9.0 and 8.2, as far as I know.
And it is assumed that the
filesystem in question on which you are about to enable
softupdates-journaling already has
softupdates enabled. If this isn't the case, perform all the steps above
execpt issuing the tunefs-command sequence as follows: tunefs -n enable
-j enable /dev/gpart/fsystem (/dev/gpt/ is used in my case since I
switched on UFS2 filesystems to
GPT partition tables). Beware! when reading the
man page of tunefs, the first option for journaling that comes to your
field of view is
the capitalized "-J" which stands for journaling via GEOM/GJOURNAL,
Scroll further and you'll pick up the lower letter "-j", which is the
option we are talking
about here. It is a little bit confusing for the first approach).
Once done, you can force on a non-important, big filesystem a crash. I
switched of one
of my server boxes with a 3 TB harddrive for test purposes and was
amazed how fast, compared to
unjournaled UFS2, the fsck now is performed.
Since *BSDs UFS2/FFS filesystem is still, even for large
disks/partitons, a competetive filesystem
and still a slightly better performing filesystem compared to ZFS and
its memory consumption,
this efford is really worth "a must have". I'm simply overwealmed at
this moment by this little pieces of
more security and performance (in case of a crash on / and large
partitions). A small piece, a great effect - I think.
maybe naiv thinking, but who cares. Thanks to those who gave this pieces
of bonbon to the community.
More information about the freebsd-current