Patch 2284 : XFS rollup #9 for 6.2 : [IRIX 6.2]
INDEX
RELATIONS
RELEASE NOTES
1. Patch SG0002284 Release Note This release note describes patch SG0002284 to IRIX 6.2. Patch SG0002284 replaces patches SG0001208, SG0001278, SG0001396, SG0001467, SG0001566, SG0001589, SG0001667, SG0001768, and SG0001907.1.1 Supported Hardware Platforms This patch contains bug fixes for all platforms.1.2 Supported Software Platforms This patch contains bug fixes for IRIX 6.2 (version 1232792137) and IRIX 6.2 with Indigo^2 Impact R10000 (version 1233007732). The software cannot be installed on other configurations.1.3 Notice of Patch Dependencies This patch must not be installed unless patch 1389 6.2 kernel rollup (or one of its successors) is already installed on the system. If patch 2284 is installed on a system without patch 1389 or one of its successors, then the kernel will fail to link. The link failure will complain that the symbol dnlc_lookup_fast_flags cannot be resolved. Included in this patch is an implementation of quotas for XFS file systems. If you intend to use quotas with your XFS file systems, then you must also install patch 1287 (or one of its successors). Patch 1287 contains modifications to the mount(1M) utility used to enable quotas on XFS file systems. If you intend to use quotas on an XFS root file system, then you must also install patch 1397 (or one of its successors) in addition to patch 1287. Patch 1397 includes a version of sash which properly recognizes XFS file systems containing quotas; without it your root filesystem will fail to mount and your system start up will fail.1.4 Enabling Quotas on XFS File Systems This section contains a brief description of how to set up quotas on a system with XFS file systems. See the quotas(4), repquota(1M), quotaon(1M), and quota(1) man pages for more details. o Install the eoe.sw.quotas subsystem from your IRIX 6.2 CD if you have not already done so. o Install patches 2284, 1287, 1389, and 1397 or their successors. o Add the quota option to the lines in the /etc/fstab file corresponding to the file systems on which you wish to enable quotas. o Reboot your system. It will come up with quotas enabled on all the file systems you specified except for the root file system. o If you want to enable quotas on the root file system, issue the command quotaon / as root, sync and reboot. Quotas will be enabled on the root file system when the system comes back up.1.5 If An XFS Root Filesystem Had Quotas Turned On ... This patch contains a fix for bug #414414 of patch 1278 which may in certain cases have made quota accounting on the root XFS filesystem inaccurate. Therefore, if an XFS root filesystem that has patch 1278 installed had quotas turned on, it is necessary that quotas be turned off (see quotaoff(1M) man page) and turned on after installing this patch. Refer to the previous section Enabling Quotas on XFS File Systems for details of the procedure.1.6 Quotas and Backing out XFS Patches Due to changes in the XFS filesystem on-disk data structures required for quotas to operate, once quotas have been enabled on an XFS filesystem from that point on, only systems running XFS rollup patch 1278 or a successor will be able to mount the filesystem. Machines running only IRIX 6.2 or IRIX 6.2 with XFS rollup patches 1208 or 1396 installed will not be able to mount a filesystem that has had quotas enabled even if the quotas are currently disabled. The quota-related changes, once made, are permanent. The only way to move a filesystem back to a pre-quota state is to xfsdump the filesystem, re-mkfs the filesystem, and xfsrestore. If quotas have never been enabled on an XFS filesystem, that filesystem will remain mountable by any IRIX 6.2 machine.1.7 DMAPI Implementation Changes Patch 2284 contains changes to the DMAPI interface. Numerous bugs have been fixed, and the current implementation of DMAPI is not compatible with previous versions of the interface (prior to patch 1907). The original DMAPI interface was intended for use in products being developed. Changes were anticipated as applications developers gained experience and as the DMAPI specification evolved. The original SGI implementation was based on version 2.1 of the specification. The current implementation is based on the X/Open document Systems Management: Data Storage Managment (XDSM) API dated February 1997. The current implementation follows the specification more closely than the previous implementation. All required functions and structures mentioned in the specification are defined and prototyped in the header file <sys/dmi.h>. Some optional components are defined but unimplemented so that an application will compile and link if the optional component is used. For example, the optional function dm_symlink_by_handle() is prototyped in <sys/dmi.h>, but a call to dm_symlink_by_handle() returns ENOSYS. The comments and prototypes in <sys/dmi.h> document differences between the SGI implementation and the DMAPI specification. The access rights mentioned in the specification are not implemented. Specifically the DMAPI functions dm_request_right(), dm_release_right(), dm_query_right(), dm_upgrade_right() and dm_downgrade_right() do not work as described in the specification. The connection between DMAPI access rights and the XFS filesystem locks is missing. However applications which do not need full rights support and which only make dm_xxx_right calls in order to satisfy the input requirements of other DMAPI calls should be able to use these routines to avoid having to implement special- case code for SGI platforms. Applications which truly need the capabilities of a full implementation of rights will unfortunately have to come up with alternate software solutions until such time as rights can be completely implemented. If you are using the DMAPI interface in patch 2284, then the base Hierarchical Storage Management Support package must have been installed first. When installing patch 2284, select both the Hierarchical Storage Management Support and the Development Execution Header subproducts. If the eoe_sw.xfs filesystem component of patch 2284 is installed with the base release of eoe_sw.dmi, the resulting kernel will generate warning messages at kernel link time. Also, the resulting kernel will not execute DMAPI functions correctly. Patch 2284 contains corrections for the DMAPI handling of memory mapped files. However, with these corrections it is possible to hang a system if a file with DMAPI managed regions is being memory mapped and if the DMAPI application needs additional memory (for itself or for spawned processes) to process the managed region request. The potential for this hang is corrected in kernel rollup patch 2119 and its successors. Following are some specific differences between the current implementation and the previous DMAPI implementation. o The function prototypes and data structures now always match the specification, except as noted earlier. o The truncate was previously missing for a file which existed but was opened with O_CREAT|O_TRUNC. o The asynchronous events are now always sent even when an operation fails. This applies to the postcreate, postremove, postrename, postlink, postsymlink, attribute, and destroy events. o The destroy event will return the attribute specified by the set_return_on_destroy() function. o The postcreate event was previously being sent even if the file was actually not created. o Previously the function dm_set_eventlist() allowed one to set the read, write, and truncate events directly on a file. Now these events must be specified using the standard function dm_set_region(). Since multiple managed regions are not supported, the region specified for dm_set_region() typically uses an offset of zero and a length of zero to specify the entire file. o Previously, memory mapped access to a file would not generate DMAPI events. This has been changed so that a read or write event will occur at the time a file is mapped. If the file is being mapped for execution (e.g., and exec type system call) the event is a read event for the entire file. If the file is being mapped by the mmap() system call, a read or write or write event for the correct range is generated. Before sending the final response for a write event, the DMAPI application must make sure that there are no longer any read or write managed regions on the file. This is necessary because in the memory map case, it is not possible to reliably detect subsequent read or write events for the mapped file. Similarly, before sending the final response for a read event, the DMAPI application must ensure that there no longer is a read managed region on the file; a write region is allowed. o The dm_assoc_handle(), dm_disassoc_handle(), dm_query_token(), and open_by_handle() functions functions have been removed.1.8 Bugs Fixed by Patch SG0002284 This patch contains fixes for the following bugs in IRIX 6.2. Bug numbers from Silicon Graphics bug tracking system are included for reference. o xfsdump/xfsrestore needs operator notification feature (bug #254345). o XFS did not have full support for punching holes in files (bug #282157). o Unmounting an XFS filesystem could take much longer than necessary (bug #303417). o A truncate system call on a fifo device special file could cause the system to panic (bug #311076). o XFS as originally released had no support for quotas (bugs #313079, #328307). o Mkfs on a Syquest removable drive would print an error message about a write failure, but actually work correctly. If a legitimate write error occurred during mkfs, it would be reported, but the mkfs would continue (bug #314110). o xfsdump now prints total size of non-dir files dumped when done (bug #315748). o xfsdump with non-variable breaks device (bug #320290). o xfs_copy now has an additional option -d. The -d option will make xfs_copy duplicate the filesystem ID (UUID). xfs_copy typically generates a new filesystem ID for duplicated filesystems. This allows the original and duplicated filesystems to be used simultaneously. The -d option allows you to generate a true copy of the original filesystem for use in circumstances when the original version will not be used again such as when trying to copy a filesystem from disks that are going bad (rfe #327721). o The progress reported by xfs_copy is also more accurate and files created by xfs_copy (target filesystem images and log files) are now created with mode 644 (read- write by owner, readable by everyone else). o xfsdump did not know about mt unload (bug #331296). o xfsdump inventory file records in progress dumps as not interrupted (bug #353197). o A deadlock was possible in XFS under heavy stress (bug #357358). o This patch and its miniroot include a program and man page for a program named xfs_repair(1M) that repairs corrupted XFS filesystems (rfe #358502). o A crash in xfs_bmap_btree_to_extents is possible in the presence of user-level attribute usage. The bug may leave a file (which may never have had attributes) in a slightly inconsistent state, causing the crash. Such files may be removed or truncated safely, but they may not be read without causing a crash. The patch contains a newer version of xfs_check, which reports the problem, as well the kernel fixes for the problem (bug #362841). o If xfsrestore is used to restore a sparse file with a hole at the very end of the file, it will not set the length of the file correctly if it has to create the file or if it has to overwrite a file and the file being overwritten is shorter than the file being restored (bug #364404). o xfsrestore can leave garbage in holes when restoring sparse files (bug #364450). 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 Previous XFS rollup patches would not install on IRIX 6.2 for Indigo2 Impact R10000. This patch and its successors will (bug #370704). o Using the O_RSYNC open flag with files in XFS file systems would cause accesses of the file after the first read to hang (bug #372806). o Running xfs_logprint on a live filesystem could result in filesystem corruption if the machine crashed immediately thereafter (bug #383270). o There was a bug in the attribute rename code which could cause a system panic (bug #383959). o Inode reads were slower than was necessary on small- block filesystems (bug #385292). o The quota and inode read changes required changing the version number in the XFS superblock. The versioning scheme has been changed to be more flexible. With this patch, if a boot filesystem is made to have the new superblock version number (for instance, by using quotas on it) then the sash patch (SG0001397 or its successor) and the mount patch (SG0001287 or its successor) are also necessary (bug #385316). o xfsdump printed a trash message when its open of a file failed (bug #385376). o Corruption in certain fields in the on disk XFS inode structure could lead to a system crash (bug #386036). o When a file is renamed its inode change time is not updated (bug #390257). o Very sparse files, with blocks separated by more than 2^32 blocks, can get corrupted when more block insertions are done (bug #391760). o A very full allocation group in a filesystem can have less than optimal blocks added to files when the file is extended (bug #392903). o xfsdump/restore malloc heap corruption when stdout/stdin is the destination/source (bug #393618). o xfsrestore 2.0 from miniroot doesn't print out progress message (bug #394225). Note that actual status update intervals may be longer than the specified (by the -p command line option) interval in this case. o A very full filesystem can cause deadlocks when directory or attribute blocks are added (bug #396248). o SHAREII disk quotas did not work on XFS filesystems (rfe #398935). o Incremental restores using xfsrestore were broken. It was not processing removes, links, and renames (bug #402614). o A crash was possible in certain cases when turning off quotas on busy XFS filesystems (bug #406540). o Turning on quota limit enforcement on root XFS filesystems required a reboot in patch 1278. That was an unnecessary restriction (bug #407732). o Edquota(1M) option -i erroneously complained when a user's hardlimit was zero and the softlimit was greater than zero (bug #408639). o xfs_logprint(1M) did not recognize XFS quota log records; it would core dump as a result. (bug #413256) o Disk quotas on XFS root filesystems was broken in patch 1278; it was possible to get inaccurate quota accounting. In extreme cases where a very large number of users owned files on the root filesystem, it was also possible for the system to hang when trying to turn quotas on. It is necessary to turn quotas off and on again on the root filesystem for rectification (bugs #414414, #406537). o Some programs accessing files via mmap(2) or using the user level semaphore facility (see usinit(2)) would core dump randomly after installing patch 1467 (bug #414919). o xfsdump not recycling tapes (bug #419313). The overwrite option fixes this problem. o A previous XFS rollup patch (patch 1278) did not contain the latest version of the quota.h header file (bug #419563). o A panic was possible in a previous XFS rollup patch (patch 1278) on XFS realtime filesystems (bug #419754). o The miniroot in this patch can support up to 40 XLV volumes. (bug #420023) o Bug #414919 would cause clogin and other desktop tools to fail on certain combinations of platforms and installed patches (bug #426893). o xfs_repair used to issue a spurious warning message about a directory entry referencing a free inode when run on a filesystem with a large root directory and an existing lost+found directory. The message was spurious since the program itself clears the lost+found inode while running and then recreates it later. So the warning message could mislead users into thinking that the filesystem was corrupt when it fact it was not (bug #427424). o xfsdump core dumps if local DAT tape starts with eof marker (bug #428476). o On a full file system, it is possible to reallocate a filesystem data block that has already been allocated which could result in a panic or corrupt the file system (bug #428626). o The quota(1) utility did not report information on autofs filesystems (rfe #433752). o xfsrestore "-i" would not work if input was from stdin (bug #435626). o xfs_repair would fail on a number of extreme filesystem corruptions (bug #437401). o xfsdump would core dump on R4600 or R5000 platforms after installing patch 1566 (bug #437495). o xfsdump 2.0 cannot determine block size on brand new tapes (bug #438657). The overwrite option fixes this problem. 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 Some utilities did not handle very large (illegal) inode values properly which could lead to incorrect behavior if the filesystem becomes corrupted (bug #439128). 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 Multiple parallel opens of a single directory could race, resulting in failure of a subsequent getdents (readdir) call (bug #442075). o On filesystems with external logs, xfs_repair would think that some number of the first blocks in the filesystem were used by both the log and the filesystem and reclaim those blocks for the log, losing data in the filesystem and possibly damaging a consistent filesystem (bug #443561). o Deadlock was possible under heavy filesystem stress (multiple threads creating and deleting files, for instance) (bug #444272). o xfsdump remote dump fails to Sun tape drive (bug #445983). o Read-only mounts of cleanly unmounted XFS filesystems would issue disk writes to the XFS log to zero parts of the log and write an unmount record and allow certain quota operations to occur. With this patch, if an XFS filesystems that was cleanly unmounted is mounted read-only, no disk writes will be issued to the filesystem (bugs #446511 and #451379). 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). o In certain rare cases, xfs_copy would not copy all the blocks in a filesystem (bug #453046). The situation that triggers the bug is a little more likely on filesystems made by IRIX 6.3 and IRIX 6.4 kernels. o xfs_repair -f (repair a filesystem in a file) didn't work (bug #453106). o xfs_repair failed on filesystems that had been grown using growfs(1), complaining that the primary superblock had a bad magic number and not finding any secondary superblocks (bug #458528). o This patch adds an internal interface between XFS and SGI's DFS implementation making it possible to patch them independently (bug #459447). o DMAPI DM_EVENT_TRUNCATE event is not sent on open(O_CREAT|O_TRUNC) (bug #459555). o DMAPI does not generate events for memory mapped files (bug #459567). o xfsdump does not work on Exabyte 8200 drive (bug #460195). o It is possible to panic recovering an XFS filesystem if the kernel log buffer data area used in recovery is adjacent to unmapped kernel virtual memory (bug #460982). o xfsdump complained about uninitialized or incompletely initialized tapes (bug #461457). o If attr_get was called with a size smaller than the actual attribute size on a shortform attribute area (fits in the inode), kernel memory corruption and/or a crash could result (bugs #462371, 511889). o xfsdump from an Origin 2000 to a remote 5.3 tape drive did not work (bug #463620). o xfs_repair can generate filesystems with incorrect freespace btrees (bug #464859). o xfsdump fails with I/O error from 6.2 to 6.4 (bug #470689) o xfsrestore inventory filter options need enhancement (bug #470701). o Under certain extremely rare circumstances, mkfs will generate a XFS filesystem that will cause a panic when used (bug #470817). o -p ###' status updates do not appear when xfsdump is to stdout (bug #473713). Note that actual status update intervals may be longer than the specified (by the -p command line option) interval in this case. o Some quota utilities like repquota and quot did not sometimes work properly when the target filesystem was lofs/autofs mounted (bug #474195). o This fix allows 6.2 kernels to mount filesystems that will be created by IRIX 6.5 (bug #474775). o For o32 applications, readdir (getdents) may skip some directory entries when seekdir is used, especially in large directories (bug #477131). o xfsdump needs "overwrite" option (rfe #477913). o edquota -i option did not interpret the limits read in from the input file in the correct units (bug #479354). o The mount system call without the dataptr argument could cause kernel memory corruptions and panics (bug #480655). o Readdir (getdents, ngetdents) calls returning 64-bit offsets were supposed to be unique offset values, and were not. This could cause infinite loops when using seekdir/telldir (bug #481782). o An error message in xfs_repair had two values reversed (bug #494004). o xfs_repair -n could hit an assert "agip->agi_seqno == agno" and core dump (bug #494069). o xfsdump did not sometimes work properly when the target filesystem was lofs/autofs mounted. The same was true for some operations in the grio subsystem (bug #500173). o attr_get, attr_remove, and attr_list would fail in some cases, returning EDIRCORRUPTED, when there were no attributes attached to the file in question (bug #503935). o Filesystems larger than 1/2 terabyte would see panics ("Invalid inode number 0xffffffffnnnnnnnn") if there were inodes in the part of the filesystem from 1/2 terabyte up to 1 terabyte (bug #504513). o On a I/O intensive system, a hang can occur between a process executing in the xfs write system call code and the xfsd daemon trying to push delayed write and delayed allocated data out to disk (bug #504578). o Adding user-mode attributes to realtime files would cause filesystem corruption (bug #511011). o Files created in the realtime area of a filesystem tend to be much more fragmented than those in the normal data area (bug #512294). o XFS performs more consistency checking when reading in inodes (bug #513540). o xfsdump needs option to generate a single media file (bug #513865). o xfsrestore does not restore mode of symbolic links (bug #513874). o fcntl(F_GETBMAP) would return an incorrect length value when the starting offset was nonzero and the last extent returned was a hole at the end of the file (bug #514488). o Realtime file allocations of at least 2^21 filesystem blocks (this is usually done with the F_RESVSP or F_ALLOCSP fcntl call) will cause a corrupted filesystem (bug #514540). o Removals of large directories can cause a kernel crash (bug #519310). o Extremely full XFS filesystems may end up with inconsistent inodes (bug #516715). o DMAPI usage can hang CPUs in mutex_spinlock (bug #519614). o This patch includes changes to make xfs_repair work against filesystems mkfs'ed by machines running IRIX 6.5 (bug #523923). o The unmount of a DMAPI filesystem may possibly panic IRIX (bug #523961). o xfsrestore returns: inv: open failed (bug #705546). The new xfsinvutil command used with the -C command line option fixes this.1.9 Subsystems Included in Patch SG0002284 This patch release includes these subsystems: o patchSG0002284.dev_man.irix_lib o patchSG0002284.eoe_man.unix o patchSG0002284.eoe_sw.quotas o patchSG0002284.eoe_sw.unix o patchSG0002284.eoe_sw.xfs o patchSG0002284.eoe_sw.xfsrt o patchSG0002284.eoe_sw.dmi1.10 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. The inst program does not allow you to install patches that are incompatible with your hardware or software. 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. Initiate the installation sequence. Type Inst> go 3. You may find that two patches have been marked as incompatible. (The installation tools reject an installation request if an incompatibility is detected.) If this occurs, you must deselect one of the patches. Inst> keep patchSGxxxxxxx where xxxxxxx is the patch number. 4. After completing the installation process, exit the inst program by typing Inst> quit1.11 Patch Removal Instructions 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. 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.1.12 Known Problems If a miniroot is booted while quotas are turned on for the root filesystem, quotas on the root filesystem will be turned off. The system administrator must go through the procedure that was described in Section 1.4 and turn quotas on again. INST SUBSYSTEM REQUIREMENTS No Requirements Information Available. INST SUBSYSTEM CHECKSUMS These checksums help to provide a 'signature' for the patch inst image which can be used to authenticate other inst images. You can obtain this kind of output by running sum -r on the image (from the command line): 06508 49 ./patchSG0002284.idb 54647 17 ./patchSG0002284.eoe_hdr 50495 173 ./patchSG0002284.eoe_man 25049 47 ./patchSG0002284.dev_man 44095 60 ./README 51317 13371 ./patchSG0002284.eoe_sw 65173 4626 ./miniroot/unix.IP22 22274 4146 ./miniroot/unix.IP20 18794 9028 ./miniroot/unix.IP21 62297 7483 ./miniroot/unix.IP26 10313 9295 ./miniroot/unix.IP25 30867 7952 ./miniroot/unix.IP28 40784 9715 ./miniroot/unix.IP19 44095 60 ./README.patch.2284 46402 15 ./patchSG0002284 INST SUBSYSTEM FILE LISTINGS The following lists the files which get installed from each subsystem in the patch:
DOWNLOAD PATCH
|
||||||||||||||||||||||||||||||||||||
Document Id: 20021117065702-IRIXPatch-1118
|