Silly Doubts ..Please help

[Dinesh_15]

can any body clear my following doubts

1) In case JFS File Systems, the Intent Log holds only the Metadata updations for the file system..If many writes are there, then there then these changes are not updated synchronously w.r.t the disk content and changes that to be made..In this situation if system crashes how the data is recoverd??
Is intent log itself a file in metadata area or data area.?
How exaclty the intent log is updated??If file system crashes the whether the system need to comapare the intent log with the actual data in the disk or simply it reads the log ..
If it just reads the log, then how the log is written .. can any body explain with just a write example to the system.

2)In case of block sizes..
Whether the filesystem block size and the disk block size are same?? What about the block size in case of databases?
whether all of them should be same for better performance?

3)What is the diffrence between no_data_in_log and asynchronous option in case of VXFS(JFS)

Rgds
Dinu

[Robert-Jan Goossens_1]

Hi Dinu,

log|delaylog|tmplog|nolog
Controls intent logging. File system integrity across system failure requires
that logging is enabled. The default is log. In log mode, file system structural
changes are logged to disk before the system call returns to the application.
If the system crashes, fsck_vxfs(1M) will complete logged
operations that have not completed. In delaylog mode, some system calls return
before the intent log is written. This improves the performance of the system,
but some changes are not guaranteed until a short time later when the intent log is written. This mode approximates traditional UNIX system guarantees for correctness in case of system failures. In tmplog mode, the intent log is almost always delayed. This improves performance, but recent changes may disappear if the system crashes. This mode is only recommended for temporary file systems. In nolog mode, the intent log is disabled. The other three logging modes provide fast file system recovery; nolog does not provide fast file system recovery. With nolog mode, a full structural check must be performed after a
crash; this may result in loss of substantial portions of the file system,
depending upon activity at the time of the crash. Usually, a nolog file system
should be rebuilt with mkfs_vxfs(1m) after a crash. The nolog mode should only be used for memory resident or very temporary file
systems.

best regards,
Robert-Jan

[RAC_1]

1. I am not very much expert in this area. I would try to help you. The vxfs options log, delaylog, nolog controls the intenet log. Intenet log logs the transactions to the FS and returns the system call. Then after certain interval, it flushes the changes to the disk. I think the size of the intent log depends on size of FS and there is more then one intenet log(not sure though) and works in cyclical fashion. i.e when one is full, the next one is taken.

2. The disk block siz and FS block size is not same. The FS block size is what "you specify on newfs command-option -b" the FS block size is the smallest unit, that can be allocated to the file. It is always better to have same block size for oracle as that of FS block size.

3. The parameter datainlog and nodatainlog affects only the small synchrneous writes(less then 8kb). with datainlog option, synchroneous writes are writtento the log and i/o is return. Then after some time, the changes are written to the disk in a single asynchroneous write. i.e with daainlog option, multiple small synchrous writes(less than 8kb) are stored in log and then written to disk afterwords. In nodatainlog, samll writes(synchroneus) are written to disk immedately.

I strongly recommand you to read following PDF document. It is very helpful to understand your queris.

http://www.docs.hp.com/hpux/onlinedocs/5576/JFS_Tuning.pdf

Anil

[Dinesh_15]

Hi Robert and Anil

Thanks for your sinsere replies.
But I still have a doubt.

Robert...
#The default is log. In log mode, file system structural
changes are logged to disk before the system call returns to the application.#
Does this mean that before call return to the application which called the updataion of data, the metadata changes are updated in Intent log.I think it is not updated to the original data content.If possible please try to elaborate with a smal write cycle.
Still my query is about the crash of file system. If FS crash occurs how system gets the previous state of the FS without actually verifying the FS , but just verifying the Intent Log.?

Anil:
Then how can we verify the disk block size. Can we change the same.How the differnce in FS block size and Database block size effetcts the system performance.
Also thanks for pointing to the Nice doc.. I am already having the doc..In fact after reading this doc only came with this doubt..

Please help

Rgds
Dinu

[Sundar_7 · Accepted solution]

Dinesh,

Let me try answering your first query.

Intent log is intended to store only the meta data updations to the filesystem and it is there to protect you from corruption to the filesystem metadata.

Intent log cannot help you in restoring a corrupt file.

I can tell you my understanding

1) There is a request for metadata updation
2) VXFS driver in the kernel writes the request to the intent log



3) Tries to flush the update to the disk
and if the update was successful, updates the corrosponding intent log entry

OK

4) If the system crashed before the meta data update could be flushed on to the disk, the status of the request will still be pending in the intent log

PENDING

5) Now when the fsck is run, it just replays the pending intent log meta data update requests.

On a nutshell, intent log will make sure the filesystem is mountable after system crash. But it is not going to help you recover corrupted files.

How the actual data is written to the disk depends on number of things, including how your application is written (if it uses sync writes or async writes). If the disks are in a disk enclosure that has inbuilt cache (like EMC disk arrays), things get ever more complex.

-- Sundar.

[Mark Greene_1]

"2)In case of block sizes..
Whether the filesystem block size and the disk block size are same?? What about the block size in case of databases?
whether all of them should be same for better performance?
"

The block sizes are different. What to set them to will vary depending on the disks, controllers, and controller cache involved. The trick is getting this information, as the disk/controller block size ususally is only found in the technical documentation.

If you are using a database and *not* using raw partition--i.e., your db is in a file system--the db partition size doesn't really matter as much as the file system block size and the disk (actually, controller), block size. If you are using raw partitions, setting the db block size and the filesystem block size to be the same will help eliminate some overhead.

mark

[Dinesh_15]

Hi Sundar and Mark

Thanks

Sundar... Thanks a lot for nice explanation.. In fact i was expecting something like this.. and Finally I got it..

Thanks everybody who answered ..

Let me to close this thread

Rgds
Dinu

[Dinesh_15]

Hi Friends

Closing the thread

Rgds
Dinu