-o logging": important? Why defaulted OFF by Sun?

A few days ago I got a post-followup (here) commenting
something like:

Please at least turn on logging!

Something I knew nothing about, file-system logging.

I read a little bit about it in the came-from-the-doc-cd documentaiton,
learning that logging would allow me to not have to fsck so
often -- and presumably would protect me from inadvertent
"L-1 A"s ("stop A"s), unattended power-outages, etc.

First -- is that true, about protecting from disk-effects from an L-1 A or
power-outage-caused crash?

Second -- if this logging is so important, why in the world
does Sun have it, by default, turned *off*?

Third -- do *you* (and you and you and you too) use it, and
why or why not?

Fourth -- if you do use it, do you turn it on for *all*
file-systems, or only some of them? (And why some and not others?)

Thanks so much!

David

David Combs <dkcombs@panix.com> wrote:
> First -- is that true, about protecting from disk-effects from an L-1 A or
> power-outage-caused crash?

Yes

> Second -- if this logging is so important, why in the world
> does Sun have it, by default, turned *off*?

Because until recently (S9U4 from memory) there were a (very, very) few
corner cases where UFS logging would result in a performance hit. In order
not to cause a regression in performance - even for only a few cases - it
was left off by default. I believe this is due to change in the next
version of Solaris...

> Third -- do *you* (and you and you and you too) use it, and
> why or why not?

Yes. Always. No exceptions.

> Fourth -- if you do use it, do you turn it on for *all*
> file-systems, or only some of them? (And why some and not others?)

All.

Scott

David Combs <dkcombs@panix.com> wrote:

> I read a little bit about it in the came-from-the-doc-cd documentaiton,
> learning that logging would allow me to not have to fsck so
> often -- and presumably would protect me from inadvertent
> "L-1 A"s ("stop A"s), unattended power-outages, etc.
>
> First -- is that true, about protecting from disk-effects from an L-1 A or
> power-outage-caused crash?

Yes.

> Second -- if this logging is so important, why in the world
> does Sun have it, by default, turned *off*?

Because it's a relatively new feature, and has had a very rare bug
until *quite* recently. For the sake of absolute safety, Sun didn't
enable this new feature by default. Also, on EXTREMELY busy filesystems,
metadata changes can suffer slightly.

Note though, I heard that logging is on by default in Solaris 10.

> Third -- do *you* (and you and you and you too) use it, and
> why or why not?

Yes, absolutely! See point #1. Also, you can expect moderate performance
gains on some operations.

> Fourth -- if you do use it, do you turn it on for *all*
> file-systems, or only some of them? (And why some and not others?)

Every filesystem on every server, INCLUDING / and /var. Some have avoided
putting it on /, but I have found no reason to do so whatsoever.

Colin

Scott Howard wrote:

> David Combs <dkcombs@panix.com> wrote:

>>Third -- do *you* (and you and you and you too) use it, and
>>why or why not?

> Yes. Always. No exceptions.

I usually it virtually always as well, but I do have one
exception: if I am copying the entire contents of a filesystem
to a new filesystem (or restoring from a backup), I temporarily
turn off logging so that I can use "fastfs". fastfs seems to
still be faster than logging, although logging is an improvement
over just a regular filesystem.

- Logan

cbigam@somewhereelse.nucleus.com wrote:
> Note though, I heard that logging is on by default in Solaris 10.

I'm not sure about Solaris 10 (the Beta has not started yet), but in
Express (I consulted build 46), logging is not on by default.

>>Fourth -- if you do use it, do you turn it on for *all*
>>file-systems, or only some of them? (And why some and not others?)
>
>
> Every filesystem on every server, INCLUDING / and /var. Some have avoided
> putting it on /, but I have found no reason to do so whatsoever.

Don't you really mean "no reason *not* to do so whatsoever"...?

David Combs wrote:
> First -- is that true, about protecting ncsfrom disk-effects from an L-1 A or
> power-outage-caused crash?

Certainly it will provide protection against the effects of the above
situations, but not all situations. I was recently installing S9U6 Beta
in a shared SCSI environment (I usually don't, but I thought
whatever...), and during the install I got 20 or more SCSI Bus resets (I
guess that the system not being installed, but still on the bus did not
like the installation's SCSI probes and resets were caused). Thereafter
on one of the shared disks I was unable to mount the filesystem (it only
has one) R/W, getting I/O errors, but able to mount R/O fine, and access
the contents fine. After some minor perspiration, I found that it was
because the log area of the filesystem had become corrupted, and had to
fsck the filesystem - 18GB and some *huge* directory hierarchies :-( I
know this is an unusual case, but it can happen.....

Don't let me put you off use of logging though. As all of the
better-informed-than-me will concur, UFS logging is the dog's orbs.

Beardy wrote:

> cbigam@somewhereelse.nucleus.com wrote:

[ logging on every filesystem? ]

>> Every filesystem on every server, INCLUDING / and /var. Some have avoided
>> putting it on /, but I have found no reason to do so whatsoever.

> Don't you really mean "no reason *not* to do so whatsoever"...?

I think the "to do so" refers to the "avoided putting it on" part.
That is, no reason to avoid it (rather than no reason to enable it).

- Logan

Beardy wrote:
> cbigam@somewhereelse.nucleus.com wrote:
>
>
>>
>> Every filesystem on every server, INCLUDING / and /var. Some have avoided
>> putting it on /, but I have found no reason to do so whatsoever.
>
>
> Don't you really mean "no reason *not* to do so whatsoever"...?


ITHM "no reason to avoid".

--
Tony

On Wed, 28 Jan 2004, Beardy wrote:

> David Combs wrote:
> > First -- is that true, about protecting ncsfrom disk-effects from an L-1 A or
> > power-outage-caused crash?
>
> Certainly it will provide protection against the effects of the above
> situations, but not all situations. I was recently installing S9U6 Beta
> in a shared SCSI environment (I usually don't, but I thought
> whatever...), and during the install I got 20 or more SCSI Bus resets (I
> guess that the system not being installed, but still on the bus did not
> like the installation's SCSI probes and resets were caused). Thereafter
> on one of the shared disks I was unable to mount the filesystem (it only
> has one) R/W, getting I/O errors, but able to mount R/O fine, and access
> the contents fine. After some minor perspiration, I found that it was
> because the log area of the filesystem had become corrupted, and had to
> fsck the filesystem - 18GB and some *huge* directory hierarchies :-( I
> know this is an unusual case, but it can happen.....
>
> Don't let me put you off use of logging though. As all of the
> better-informed-than-me will concur, UFS logging is the dog's orbs.

Thats a very special case and of course, shared scsi environments aint
supported unless your running cluster to my knowledge.

/Johan A

dkcombs@panix.com (David Combs) writes:

>-o logging": important? Why defaulted OFF by Sun?

It defaults to off because at this point Solaris has trouble
booting from a logging "/" device if it has been modified.
(the boot code currently doesn't understand nor even looks at the
log)

When you install patches with a logging "/" you should
"lockfs -f /" prior to doing a reboot.

Until the code is written which allows booting with a dirty log,
it can't be the default.

>First -- is that true, about protecting from disk-effects from an L-1 A or
>power-outage-caused crash?

Not so much protection as well as more quickly recovering.

>Second -- if this logging is so important, why in the world
>does Sun have it, by default, turned *off*?

>Third -- do *you* (and you and you and you too) use it, and
>why or why not?

I use it for all my disks.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.