What Are The Performance Enhancements In Gfs2 As Compared To Gfs?

1.	What Are The Performance Enhancements In Gfs2 As Compared To Gfs?
Answer» Better performance for heavy usage in a single directory Faster synchronous I/O operations Faster cached reads (no locking overhead) Faster direct I/O with preallocated files (provided I/O size is reasonably large, such as 4M blocks) Faster I/O operations in general Faster Execution of the df command, because of faster statfs calls Improved atime mode to reduce the number of write I/O operations generated by atime when compared with GFS GFS2 supports the following features. extended FILE ATTRIBUTES (xattr) the lsattr() and chattr() attribute settings via standard ioctl() calls nanosecond timestamps GFS2 uses less kernel memory. GFS2 requires no metadata generation numbers. Allocating GFS2 metadata does not require reads. COPIES of metadata blocks in MULTIPLE journals are managed by revoking blocks from the journal before lock release. GFS2 INCLUDES a much simpler log manager that knows nothing about unlinked inodes or quota changes. The gfs2_grow and gfs2_jadd commands use locking to prevent multiple instances running at the same time. The ACL code has been simplified for calls like creat() and mkdir(). Unlinked inodes, quota changes, and statfs changes are recovered without remounting the journal.

Answer»

Better performance for heavy usage in a single directory
Faster synchronous I/O operations
Faster cached reads (no locking overhead)
Faster direct I/O with preallocated files (provided I/O size is reasonably large, such as 4M blocks)
Faster I/O operations in general
Faster Execution of the df command, because of faster statfs calls
Improved atime mode to reduce the number of write I/O operations generated by atime when compared with GFS
GFS2 supports the following features.
extended FILE ATTRIBUTES (xattr)
the lsattr() and chattr() attribute settings via standard ioctl() calls
nanosecond timestamps
GFS2 uses less kernel memory.
GFS2 requires no metadata generation numbers.
Allocating GFS2 metadata does not require reads. COPIES of metadata blocks in MULTIPLE journals are managed by revoking blocks from the journal before lock release.
GFS2 INCLUDES a much simpler log manager that knows nothing about unlinked inodes or quota changes.
The gfs2_grow and gfs2_jadd commands use locking to prevent multiple instances running at the same time.
The ACL code has been simplified for calls like creat() and mkdir().
Unlinked inodes, quota changes, and statfs changes are recovered without remounting the journal.

Discussion