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
_______________________________________________
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"
