why we are using option rw,suid,largefiles,nolargefiles,delaylog,datainlog,quota in vxfs

[Ganesan R]

Hi Senthil,

Intent log is the portion of filesystem metadata area which keeps I/O transaction details.

JFS keeps a record of all transactions to the file system metadata area in an intent log. The intent log is used for system recovery in case of a system crash. If a
file system update is completed successfully, a "done record" is written to the intent log showing that this update request was successful. In case of a system crash, the intent log is consulted and the file system brought to the stable state by removing all unsuccessful transactions with the help of the intent log.

If fsck is run on JFS, it checks the intent
log and commits any pending changes in the intent log.

[Bijeesh]

The basic idea is simple. Before performing an operation, a record of the intent to perform it is written to medium such as disk. After the operation is performed, another record is written. Usually, an operation will change some data in a system. In some cases, the intent record will contain a copy of the data before and after the operation.

Of course, this adds overhead, sometimes a lot of overhead. Enough data is written to the log to either redo or to undo the operation later.

Suppose that a failure occurs along the way. When the system is recovering, it can use the intent log to detect what operations were still in flight during the failure, and use the intent log to help recover from the failure, usually by either undoing a partially completed operation, or by redoing one that might need to be completed.

[Steven E. Protter]

Please no points.

I absolutely blew my post. I wrote file system when I should have written files.

largefiles option, now provided by newfs and not fstab permits FILES bigger than 8 GB. It has nothing to do with file system limits.

Short circuit in my brain.

SEP

[Patrick Wallek]

>>largefiles option, now provided by newfs and
>>not fstab permits FILES bigger than 8 GB.

Well, not exactly. largefiles still provides for files larger than 2GB. There has never, at least to my knowledge, been an issue with having files larger than 8GB on a file system.

The issue with 8GB files was with 'tar' and 'pax'. They were not able to **archive** files larger than 8GB without being patched. This, however, is a separate issue from the largefiles filesystem mount option.

[senthil_kumar_1]

so which is best

delaylog or nodelaylog?

datainlog or nodatainlog?

[Duncan Edmonstone]

if one option was "best", then what would be the point in having options?

This of course depends on what you are using the filesystem for... read the man page for mount_vxfs - that should tell you the differences... generally however these options are a toss-up between performance and willingness to lose data...


HTH

Duncan

[senthil_kumar_1]

Pls, I am not able to understand from man pages.

Pls explain me in practically.

about datainlog / nodatainlog
about delaylog / nodelaylog
about suid

[Steven E. Protter]

Trying again, hoping to avoid any more mistakes.

Prior post: 2 GB file size limit, not 8 GB DOH!

about datainlog / nodatainlog
about delaylog / nodelaylog
about suid

http://docs.hp.com/hpux/pdf/B2355-90672.pdf

This document explains the delaylog and other journal logs better than I can. These options impact performance and how a file system can be recovered.

suid options let you at mount time add additional security to a filesystem.

You can make it impossible to create suid files on the file system. These files can be given root privileges and therefore represent a security hazard. The passwd command is a good example. Check the permission on it. It can update /etc/passwd a root file.

Preventing the creation of suid files on a file system is an excellent security measure.

SEP

[James R. Ferguson · Accepted solution]

Hi:

> SEP: largefiles was dropped as an fstab option in 11.11. Try putting it in there and mounting it won't work.

No, you keep saying this and this is wrong.

The 'largefiles' or 'nolargefiles' option as placed in '/etc/fstab' _only_ tells you the intention at mount-time. That is, if 'nolargefiles' is set there, and you try to mount a fileystem with a 'largefiles' bit set, the mount fails.

You can add the setting as a doumentary thing if you want, but it's the underlying filesystem setting that matters. One way to test the state of a filesystem's 'largefiles' ability is to use 'mkfs -m'.

> SEP: [ nosuid option ]...can make it impossible to create suid files on the file system.

Wrong again. If a filesystem is mounted with the 'nosuid' option, then any subsequent attempt to execute a SETUID file will result in a warning message and the effective UID will _not_ be set. Execution will continue as if the SETUID bit were _not_ set, though:

To see this, mount, or remount a filesystem with the 'nosuid' option:

# mount -F vxfs -o delaylog,nosuid,remount /myfs
# touch /tmp/mysuid
# chmod 4555 /tmp/mysuid
# ls -l /tmp/mysuid
-r-sr-xr-x 1 root sys 0 May 9 12:23 /tmp/mysuid

...The file now has the 'suid' bit but the filesystem doesn't allow its enforcement as follows:

# /tmp/mysuid
/tmp/mysuid: Setuid execution not allowed

Regards!

...JRF...

[James R. Ferguson]

Hi (again):

Sorry, I made a typo and hence for the sake of my example's clarity I'll repost the 'nosetuid' test, correcting the name of the mountpoint to that which I actually used:

# mount -F vxfs -o delaylog,nosuid,remount /tmp
# touch /tmp/mysuid
# chmod 4555 /tmp/mysuid
# ls -l /tmp/mysuid
-r-sr-xr-x 1 root sys 0 May 9 12:23 /tmp/mysuid

...The file now has the 'suid' bit but the filesystem doesn't allow its enforcement as follows:

# /tmp/mysuid
/tmp/mysuid: Setuid execution not allowed

Then, to allow the execution, do:

# mount -F vxfs -o delaylog,suid,remount /tmp
# /tmp/mysuid

Regards!

...JRF...