========================================================================== The checksum's (found through sum -r) of the files that you have received (other than this README) are as follows: 64133 2 patchSG0001409 45878 3977 patchSG0001409.eoe2_sw 45250 5 patchSG0001409.idb ========================================================================== - 1 - 1. Patch_SG0001409_Release_Note This release note describes patch SG0001409 to IRIX 5.3 with XFS and 5.3 Indy R5000 with XFS. Patch SG0001409 replaces patches SG0000307, SG0000371, SG0000457, SG0000503, SG0000538, SG0000598, SG0000602, SG0000700, SG0000748, SG0000775, SG0000996, and SG0001264. 1.1 Warnings This patch changes the format of some of the data written to the log of XFS file systems. Because of this and the fact that XFS root file systems are not unmounted cleanly in the system shutdown process, this patch must not be removed once it has been installed and an XFS file system has been used for the root file system. For non-root file systems, it will be possible to remove the patch as long as the file systems are unmounted cleanly before doing so. If these restrictions are not followed and the patch is removed, it will not be possible to mount the XFS file systems using the kernel not containing the patch. This means that if you have loaded this patch and have an XFS root filesystem, the standard IRIX 5.3 with XFS installation tools found on the IRIX 5.3 with XFS CD (p/n 813-0323-001) will not work properly. Specifially, the root filesystem will not be able to be mounted. Therefore, it is imperative that you save the installation tools that you received with this patch for use at a later date. Note that this restriction will be lifted at the next release of the operating system. If you install this patch, and if you are exporting filesystems over NFS, you must have NFS patch SG0000547 or one of its successors (SG0000920, SG0001102, or SG0001477, at this time) installed, or the system may panic during the export operation. 1.2 Supported_Hardware_Platforms This patch contains bug fixes for the following machine types. The software cannot be installed on other configurations: o Challenge and Onyx with R4400 processors o Crimson (4D/510) o PowerSeries (4D/120, 4D/2xx, 4D/3xx and 4D/4xx) - 2 - o Indigo and Indigo2 o Indy and Challenge S with R4xxx and R5000 processors 1.3 Supported_Software_Platforms This patch contains bug fixes for IRIX 5.3 with XFS and 5.3 Indy R5000 with XFS. The software cannot be installed on other configurations. 1.4 Bugs_Fixed_by_Patch_SG0001409 This patch contains fixes for the following bugs in IRIX 5.3 with XFS and 5.3 Indy R5000 with XFS. Bug numbers from Silicon Graphics bug tracking system are included for reference. o There is a very slight chance that the kernel could panic when an XFS file system becomes full (bug 254266). o The implementation of the Data Management API is incomplete in 5.3 with XFS. This patch includes the pieces which were missing (bug 258113). o XFS file systems with small block sizes perform badly on operations which scan large numbers of inodes, e.g. du or find. This patch alters XFS to use larger buffers for reading, writing, and caching inodes in small blocks size file systems (bug 259540). o A process reading from a file in an XFS file system using direct I/O could panic the system if it reads beyond the end of the file (bug 260200). o When it encounters an error, xfs_growfs (actually the syssgi(XFS_FSOPERATIONS) code supporting it) leaves the buffer for the disk block which encountered the error locked. Any subsequent attempts to run xfs_growfs will become stuck waiting for that buffer to be unlocked (bug 261003). If this problem occurs using XLV to grow the volume containing the file system, the fix for XLV in patch 301 will very likely be required as well. o Processes trying to read an XFS file at a constant rate will sometimes encounter delays in the time it takes for a read to complete. This is due to interference from the periodic file system sync process and a problem with the file cache taking too much memory. This patch fixes the sync problem, and the file cache problem is fixed in patch 288 (bug 261228). - 3 - o The xfs_check utility would core dump under certain conditions on an unrecovered file system (bug 261860). o Performing a file create system call on an XFS file system root directory or the ".." entry of an XFS directory would cause the process to hang indefinitely. Other processes trying to traverse that directory would become hung as well (bug 263205). o The NFS server implementation in Irix did not return any value in the microseconds field for the modify time on the return from a getattr call (rfe 251693). o The XFS code can panic complaining that a log reservation has come up short (bug 270243). o Doing an 'ls' of small XFS directories over NFS can fail from some other companies' NFS clients. This causes the directory to appear empty or for 'ls' to return errors from those client machines (bug 260747). o Large writes to the realtime subvolume of a filesystem would fail if there was not much free space in the data subvolume (bug 267936). o When using DIRECT_IO to read an XFS file, where the size of the file is not an even multiple of 512 bytes, an error will occur when trying to read the last block of the file. The read system call will return an error or the process will hang (bug 274423). o After booting a new kernel with added or deleted filesystems, NFS clients may get bogus filehandle or stale filehandle messages. For example, adding the NFS3 filesystem or deleting the efs filesystem can cause the problem (bug 274345, 278660) o The DMAPI event state isn't cleared in the on-disk inode when a file is removed. When an inode is reused, the new file may already have DMAPI events enabled. (bug 275732) o The file system might not recover correctly after a crash. o Small, synchronous writes to an XFS file were particularly slow. This has been fixed by reducing the amount of unnecessary I/O done for each write (bug 268182). - 4 - o The filesystem will crash the kernel when looking up an entry in a corrupted directory. While directories are not supposed to become corrupted, this can happen due to disk failures or XFS recovery bugs. With this fix references to such entries will return errors rather than crashing the system (bug 271325). o If an NFS client performs a directory lookup using a file which is not a directory, the system will crash or return incorrect results. The problem is not possible if the NFS client is an SGI machine running a recent release (bug 278247). o The system could crash due to a race condition in the XFS transaction code for managing kernel buffers (bug 252383). o Installing patch 538 caused direct I/O to XFS files to stop working (bug 282906). o The filesystem will sometimes crash the kernel in the xfs_trans_chunk_committed() routine (bug 283739). o Programs calling msync(2) or fsync(2) on files residing in XFS filesystems would sometimes hang for up to 10 seconds before returning from the system call (bug 283854). o XFS can sometimes crash in the transaction code due to a race condition in the log callback code (bug 275579). o XFS can sometimes appear to freeze up for no reason (bug 285600). o XFS can become deadlocked when there is a very large amount of inode update activity (bug 290906). o Writes to XFS files using direct I/O do not return errors properly when something is wrong. Instead, small random values are returned (bug 291541). o Doing direct I/O writes to a file with pending buffered writes can cause the direct I/O writes to fail (bug 291544). o Running Oracle on XFS files can occasionally cause the file system to hang (bug 295302). o Systems configured with 512MB or greater of memory may panic due to a TLB miss when running xfsdump (bug 297658). - 5 - o Checking for link count overflows is done incorrectly, so if more than 32767 links are created to a file, the file will effectively disappear; similarly with a directory with more than 32765 subdirectories (bug 301574). o The file system could become corrupt or hang during recovery due to a bug in the recovery code. The code was also too fragile in that it would hang when it could instead repair the problem (bug 253058). o The system will panic if a program makes a truncate(2) or ftruncate(2) system call with a named pipe as the argument on an XFS file system (bug 311076). o The system will panic with the message, "xfs_log_write: reservation ran out. Need to up reservation." (bug 310973) o Direct I/O accesses to a file are not coherent with normal, buffered accesses to the file. This has been fixed (bug 280514). o Stat(2) calls on XFS files return too small of values in the st_blksize field of the stat structure. This causes the stdio library to use smaller than optimal buffers (bug 330599). o Using the rename(2) system call to move a directory over top of another directory would fail to properly decrement the link count of the moved directory's old parent. This would slightly corrupt the file system (bug 322938). o On file systems with small logs the system would sometimes lock up under heavy load (bug 301882). o The file system code will panic in the xfs_iunlink() routine complaining that an inode is already in the unlinked inode list. The race condition which caused this problem is now fixed (bug 334338). o If multiple filesystems with the same unique ID (caused by a bug in the unique ID generation code), are mounted and exported via NFS, the exports will not work correctly. This change updates the unique IDs that are duplicated (bug 365043). o For improved performance, the inode buffer size is now 8kb on systems with more than 32MB of memory, 4kb otherwise (bugs 284911, 350478). - 6 - o xfs_logprint could corrupt filesystems if run when the filesystem was mounted, by writing some data into the log. If a crash followed that used the xfs_logprint- written data, either an unmountable or corrupted filesystem would result (bug 383270). o XFS filesystems built with IRIX 6.2 XFS+patch 1278 (or later) may be set up with a version number in the filesystem that is not recognized by previous versions of XFS. The patch changes the version number back to one recognized by IRIX 5.3 with XFS when it is safe to do so. Such a filesystem may be mounted, but it may not be booted from until after it has been corrected by mounting it. (bug 385316) o File handles (for NFS exports) were generated differently in this release than in later releases of XFS, so that some filesystems would not match up if exported by two different servers in a FailSafe configuration (bug 423788). o Bug in the allocator code where we would use a previously allocated block which could result in a panic or corrupt the file system (bug 439096). o Symbolic link values whose length was greater than or equal to 512 bytes in a 512-byte block filesystem could cause memory corruption during filesystem recovery (bug 440334). o Symbolic links which did not fit in the inode, and were removed before a crash, could result in corruption with the symbolic link value reappearing in the block even though it was used for something else (bug 440477). o Truncate system calls to files in XFS filesystems did not check for write permission correctly. A current kernel rollup patch is also required for the complete fix to this problem (bug 447743). 1.5 Subsystems_Included_in_Patch_SG0001409 This patch release includes these subsystems: o patchSG0001409.eoe2_sw.xfs - 7 - 1.6 Installation_Instructions Because you want to install only the patches for problems you have encountered, patch software is not installed by default. After reading the descriptions of the bugs fixed in this patch (see Section 1.3), determine the patches that meet your specific needs. If, after reading Sections 1.1 and 1.2 of these release notes, you are unsure whether your hardware and software meet the requirements for installing a particular patch, run inst. Patch software is installed like any other Silicon Graphics software product. Follow the instructions in your Software Installation Administrator's Guide to bring up the miniroot form of the software installation tools. Follow these steps to select a patch for installation: 1. At the Inst>prompt, type install patchSGxxxxxxx where xxxxxxx is the patch number. 2. Select the desired patches for installation. 3. Initiate the installation sequence. Type Inst> go 4. You may find that two patches have been marked as incompatible. If this occurs, you must deselect one of the patches. Inst> keep patchSGxxxxxxx where xxxxxxx is the patch number. 5. After completing the installation process, exit the inst program by typing Inst> quit To remove a patch, use the versions remove command as you would for any other software subsystem. The removal process reinstates the original version of software unless you have specifically removed the patch history from your system. - 8 - versions remove patchSGxxxxxxx where xxxxxxx is the patch number. To keep a patch but increase your disk space, use the versions removehist command to remove the patch history. versions removehist patchSGxxxxxxx where xxxxxxx is the patch number.