Re: howto: enabling journaling on softupdates

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>
>
> Ian
>
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 
type either
n for NO or y for YES. One can avoid this by issuing "fsck -y". This is 
for selective
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, 
another method.
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.

Oliver