hello everyone,
Could someone explain me, what does mean "is logging" when the system boots up:
/dev/rdsk/c0t0d0s1: is logging
What is the purpose of doing this procedure?
And why only certain slices are being processed. Is there any settings fo that?
thanks in advance
It means that the volume has been configured as a "transactional volume" but I would expect the devices to be specified as such e.g. /dev/md/dsk/d61 rather than /dev/rdsk/c0t0d0s1. I would think that the transactional volume configuration was never properly completed.
Ref:
Example�Creating a Transactional Volume for a Slice (Solaris Volume Manager Administration Guide)
Try searching this forum and/or Google for "Solaris transactional volume".
Traditionally each Unix file system is to be fsck'ed during system boot.
Since Solaris 7 logging (others say journaling) was introduced; the "intent log" in the file system obsoletes the fsck. (Since Solaris 8 logging is default.)
When the system boots it says "is logging" when it skips the fsck.
--
Just seeing the other reply; the Solaris Volume Manager (old name is "Disk Suite") provides another type of logging where the intent log is on a separate volume. This kind of logging is actually older, and also says "is logging" (and skips fsck) during a system boot.
Hello guys,
To MadeInGermany. I could not understand this part of the sentence.
Also, why one machine does logging of slice1 only, and another one does logging of slice 1 and slice 5? Is there any reasons for that?
If I get it correctly.
Am I correct?
To me more or less clear what processes the fsck.
So, I'm interested in the word logging what does it really means in this case? I would like to hear understable answer on that. What happens literally with the certain slice while logging.
Also hicksd8 wrote,
Could you explain understandable what does it mean and provide an example? If it's possible of course.
P.S. As far as I remember there were six slices configured during installation and we had nothing noticed in the settings about "whether configure certain slice as tranactional or not".
Wolfgang
Sure, on the first disk, there are two ufs file system with logging enabled, s1 and s5 while on the second disk, only slice 1 is containing an ufs file system.
There is no use for logging with the swap slice, because there is no file system on it in the first place. Slice 2 being the wole disk must not have loggin enabled, that wouldn't make sense. Either the other partitions are raw devices for some application needing them, or are using ZFS, are spare partitions, or are just empty.
When the OS boots and try to mount the file systems that need to, it first check if each file system has been properly unmounted, which should be the general case. The file system is then in a clean state and no fsck is performed.
If the file system state in not "clean", that means it wasn't unmounted properly or at all, for example because there was a power failure, a system panic, the disk was unplugged and similar situations. In such case, if the file system has logging enabled, instead of launching fsck, the OS only has to verify the last write/delete transactions were already performed, and replay the ones that weren't, if any. If the file system hasn't logging enabled, fsck is used and can take a long period of time because the OS need to explore the whole directory tree to see if everything is fine, fix inconsistencies and salvage files that would have been lost otherwise by copying them to the lost+found directory.
So logging speeds up mount after crash operations.
Note that you might ask fsck to check an ufs file system anyway because a corruption can be due to other causes, like bad blocks, faulty controllers or cables.
The only file system that fully removes fsck requirement is ZFS. With it, all operations are transaction so are either committed or not recorded and all blocks are checksummed so the OS knows if their content is reliable or not. The file system cannot be corrupted by a brutal shutdown.
Logging means all operations that change the contents of a file system are written in a "journal", a log, which is in a different location than the data. This journal contains all metadata operations (not the data ones) and is being written synchronously (writes are immediately flushed) so is consistent, unlike the regular data and metadata writes which might be reordered to speed up the process, and which are not immediately performed (buffering).
That's expected, logging is enabled by default because the is no reason not to do it.
Type
mount | grep /dev/dsk/
to see the current mount options.
If they are not set in /etc/fstab then they are the default.
man mount_nfs
gives another good explanation of the logging option.
So, considering that's written above and having this (see code) every start:
/dev/rdsk/c0t0d0s1: is logging [swap]
/dev/rdsk/c0t0d0s5: is logging [opt]
It may say that after every system shutdown this mashine had some issues that you described above, I guess. Am I correct?
AFAIR it looks at the logging first, and if positive does not look at the clean flag.
Well, I'm somewhat surprised that the OS tells the swap is logging, which doesn't make sense to me, but in any case, no issue is reported here. The "is logging" message is just informative.
---------- Post updated at 22:47 ---------- Previous update was at 22:38 ----------
Typo here, that's:
man mount_ufs
Well, I'm somewhat surprised that the OS tells the swap is logging, which doesn't make sense to me,
but in any case, no issue is reported here. The "is logging" message is just informative.
So I'm interested in "is logging", because brand new machines display "is logging" only for slice s5,
which is mounted to [opt], and one of the machines does "is logging" for slices s1[swap] and s5 [opt].
Just out of interest. Did ZFS really show its resistance to brutal power failures? (any comments, youre opnion based on youre experience, please).
Wolfgang