README VERSION : 1.1 README CREATION DATE : 2015-04-20 PATCH-ID : 6.2.1.000 PATCH NAME : VRTSvxfs 6.2.1.000 BASE PACKAGE NAME : VRTSvxfs BASE PACKAGE VERSION : 6.2.0.000 SUPERSEDED PATCHES : 6.2.0.100 REQUIRED PATCHES : NONE INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : rhel6_x86_64 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : CORE , HANG , MEMORYLEAK , PANIC , PERFORMANCE PATCH CRITICALITY : CRITICAL HAS KERNEL COMPONENT : YES ID : NONE REBOOT REQUIRED : NO REQUIRE APPLICATION DOWNTIME : Yes PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to Install guide for install instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to Install guide for uninstall instructions SPECIAL INSTRUCTIONS: ----------------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- PATCH ID:6.2.1.000 3093833 (3093821) The system panics due to referring freed super block after the vx_unmount() function errors. 3657150 (3604071) High CPU usage consumed by the vxfs thread process. 3657151 (3513507) Filesystem umount() may hang due to deadlock in kernel 3657152 (3602322) Panic while flushing the dirty pages of the inode 3657153 (3622323) Cluster Filesystem mounted as read-only panics when it gets sharing and/or compression statistics with the fsadm_vxfs(1M) command. 3657156 (3604750) The kernel loops during the extent re-org. 3657157 (3617191) Checkpoint creation takes a lot of time. 3657158 (3601943) Truncating corrupted block map of a file may lead to an infinite loop. 3657159 (3633067) While converting from ext3 file system to VxFS using vxfsconvert, it is observed that many inodes are missing.. 3665980 (2059611) The system panics due to a NULL pointer dereference while flushing bitmaps to the disk. 3665984 (2439261) When the vx_fiostats_tunable value is changed from zero to non-zero, the system panics. 3665990 (3567027) During the File System resize operation, the "fullfsck flag is set. 3666007 (3594386) On RHEL6u5, stack overflows lead to system panic. 3666008 (3616907) System is unresponsive causing the NMI watchdog service to stall. 3666010 (3233276) With a large file system, primary to secondary migration takes longer duration. 3683470 (3682138) The VxVM symbols are released before the VxFS modules unload time. 3687679 (3685391) Execute permissions for a file not honored correctly. 3697142 (3697141) Added support for Sles12 3697966 (3697964) The vxupgrade(1M) command fails to retain the fs_flags after upgrading a file system. 3698165 (3690078) The system panics at vx_dev_strategy() routine due to stack overflow. 3706864 (3709947) The SSD cache fails to go offline due to additional slashes "//" in the dev path of the cache device. 3710794 (3710792) Unmount fails when the mount point contains a special character(colon). 3715567 (3715566) VxFS fails to report an error when the maxlink and nomaxlink options are set on file systems having disk layout version (DLV) lower than 10. 3716627 (3622326) During a checkpoint promote, a file system is marked with a fullfsck flag because the corresponding inode is marked as bad. 3717895 (2919310) During stress testing on cluster file system, an assertion failure was hit because of a missing linkage between the directory and the associated attribute inode. 3718542 (3269553) VxFS returns inappropriate message for read of hole via Oracle Disk Manager (ODM). 3721458 (3721466) After a file system is upgraded from version 6 to 7, the vxupgrade(1M) command fails to set the VX_SINGLEDEV flag on a superblock. 3726403 (3739618) sfcache command with "-i" option maynot show filesystem cache statistic periodically. 3727166 (3727165) Enhance RHEV support for SF devices for identification in Guest 3729704 (3719523) 'vxupgrade' retains the superblock replica of old layout versions. 3733812 (3729030) The fsdedupschd daemon failed to start on RHEL7. 3737330 (3737329) Added support for RHEL7.1 3743913 (3743912) Users could create sub-directories more than 64K for disk layouts having versions lower than 10. 3745651 (3642314) Umount operation reports error code 255 in case of write-back cache. 3749727 (3750187) Internal noise testing hits debug assert. 3749776 (3637636) Cluster File System (CFS) node initialization and protocol upgrade may hang during the rolling upgrade. 3755796 (3756750) VxFS may leak memory when File Design Driver (FDD) module is unloaded before the cache file system is taken offline. PATCH ID:6.2.0.100 3703631 (3615043) Data loss when writing to a file while dalloc is on. 3723334 (3723336) On RHEL 6.6, umount(8) system call hangs if an application is watching for inode events using inotify(7) APIs. SUMMARY OF KNOWN ISSUES: ----------------------------------------- 3657168 (3331273) [FALCON]-[CFS-noise-L4]-[RHEL6.4]-SSD read cache hit an assert "Oops: 0000 [#1] SMP" with command vx_msg_thread. 3718284 (3723701) [AxRT][6.2.1MR][MANUAL][REMOTE CACHING][WRITEBACK CACHING] I/O operation get failed after rebooting second node. 3740864 (3038285) Null pointer dereference in vx_bmap_lookup ["f:vx_reorg_emap:10"] 3741021 (3741020) "tail -f" for a cluster filesystem file only works correctly on the system that is writing to the file. 3752475 (3758102) [LxRT][6.2.1MR][CACHE_DISABLED][CFS][Stress][L4] test hit an assert "Oops: 0000 [#1] SMP". 3754495 (3759788) [Linux][6.2.1MR][SLES11][Manual][Observed invalid statistics after vxupgrade on secondary node.] 3760184 (3760172) when hardlinks are present in the file system sfcache list shows incorrect stats 3760221 (3760219) lxrt:6.1.0:sfcfsha:ssd:rhel6_u4_x86_64:FS cached data is not invalidated after restoring from VM snapshots. 3760226 (3765921) lxrt:6.2.1:sfcfsha:rhel7u1:x86:manual:Some PAM related error messages for smbd daemon are observed in system logs after adding cifs share 3760230 (3760225) axrt:6.1:sfrac:table moves with all its extents to the target tier even if move the table with specified extents. 3760243 (3760242) [VxFS][fsppadm] 3760258 (3760253) lxrt:6.1.0:sfcfsha:rhel64:vxfs_wb_cache:WB caching happens for a CFS though the mode is shown as "nocache" on one nodes by sfcache list command and OS mount command shows the CFSes as unmounted which actually mounted at kernel level as in /proc/mounts. 3760273 (3323152) RHEL6.3:CCT:NOde Panic with OS bug"kernel BUG at fs/dcache.c:670!" 3760281 (3331276) Potential IRWLOCK related deadlock in page fault handler in the presence of compressed extents 3762295 (3348520) Longevity:S4(VxFS_NEW):RHEL: fsadm hung with "vxg_svar_sleep_unlock+0x76/0xd0 [vxglm]" 3762299 (3348534) Longevity:Vxfs_New(S4):Aix:DEDUP_ERROR Error renaming ~dedup_ckpt_ref checkpoint to ~dedup_ckpt_ops checkpoint on filesystem. 3762790 (2389318) hit panic with small File System on DA setup 3762919 (3602082) lxrt:6.2.0:sfcfsha:rhel7_x86_64:tab auto-complete for vxfs does not work. 3762983 (2438368) dalloc getting off while adding more than 4 volumes in vset 3762988 (2560357) LxRT: Task hung messages from RHEL6 kernel 3763244 (3766074) [LxRT][6.2.1MR][RHEL6][CAVFQA] cfsmntadm_clone test is failed due to cfsumount operation failed on checkpoint. 3768320 (2691654) On Linux system unable to select ext4 from the FileSystem 3770314 (3770312) Document known Linux Redhat OS vulnerability KNOWN ISSUES : -------------- * INCIDENT NO:3657168 TRACKING ID:3331273 SYMPTOM: Certain I/O errors during clone deletion may lead to system panic. WORKAROUND: None * INCIDENT NO:3718284 TRACKING ID:3723701 SYMPTOM: writeback cache is not supported on cluster in FSS scenario. WORKAROUND: Appropriate handling is done in the code s.t if the above scenario can't be enabled. * INCIDENT NO:3740864 TRACKING ID:3038285 SYMPTOM: Panic due to null pointer de-reference in vx_bmap_lookup WORKAROUND: Resize the file system with the fsadm command from the primary node of the cluster. * INCIDENT NO:3741021 TRACKING ID:3741020 SYMPTOM: tail -f run on a cluster file system file only works correctly on the local node WORKAROUND: To revert to the old behavior, you can specify the ---disable-inotify option with the tail command. * INCIDENT NO:3752475 TRACKING ID:3758102 SYMPTOM: In Cluster File System(CFS) on linux, stack may overflow while creating ODM file. WORKAROUND: No * INCIDENT NO:3754495 TRACKING ID:3759788 SYMPTOM: Command sfcache (1m) with stat option shows garbage value on secondary node for file system upgraded using vxupgrade(1m) command. WORKAROUND: Unmount the file system on secondary node and mount again with appropriate SmartIO options. * INCIDENT NO:3760184 TRACKING ID:3760172 SYMPTOM: When hard links are present in the file system, the sfcache list command shows incorrect cache usage statistics WORKAROUND: None. * INCIDENT NO:3760221 TRACKING ID:3760219 SYMPTOM: A restored volume snapshot may be inconsistent with the data in the SmartIO VxFS cache WORKAROUND: Purge the file system data from the SmartIO cache after restoring the volume snapshot. # sfcache purge {mount_point|fsuuid} * INCIDENT NO:3760226 TRACKING ID:3765921 SYMPTOM: On RHEL7 onwards, pluggable Authentication Modules(PAM) related error messages for Samba daemon may be observed in system logs after adding Common Internet File System(CIFS) share and the CIFS share is may not be accessible from windows client. WORKAROUND: Set aobey pam restrictions = noa in /opt/VRTSvcs/bin/ApplicationNone/smb.conf before doing cfsshare config and adding share. * INCIDENT NO:3760230 TRACKING ID:3760225 SYMPTOM: The fsappadm subfilemove command moves all extents of a file WORKAROUND: On the CFS primary node, determine the primary node using one of the following commands: # fsclustadm showprimary mountpoint # fsclustadm idtoname nodeid * INCIDENT NO:3760243 TRACKING ID:3760242 SYMPTOM: When in-place and relocate compression rules are in the same policy file, file relocation is unpredictable WORKAROUND: Create a different policy file for each policy, and enforce the policy as per the required sequence. * INCIDENT NO:3760258 TRACKING ID:3760253 SYMPTOM: On CFS, SmartIO is caching writes although the cache appears as nocache on one node WORKAROUND: Verify that the file system is mounted through the contents of the /proc/mounts file. * INCIDENT NO:3760273 TRACKING ID:3323152 SYMPTOM: The system panics with the panic string "kernel BUG at fs/dcache.c:670!" WORKAROUND: None * INCIDENT NO:3760281 TRACKING ID:3331276 SYMPTOM: The file system may hang when it has compression enabled WORKAROUND: None * INCIDENT NO:3762295 TRACKING ID:3348520 SYMPTOM: In a CFS cluster, that has multi-volume file system of a small size, the fsadm operation may hang WORKAROUND: None * INCIDENT NO:3762299 TRACKING ID:3348534 SYMPTOM: The file system deduplication operation fails with the error message "DEDUP_ERROR Error renaming X checkpoint to Y checkpoint on filesystem Z error 16" WORKAROUND: Retry the deduplication operation to resolve the problem. * INCIDENT NO:3762790 TRACKING ID:2389318 SYMPTOM: Enabling delayed allocation on a small file system sometimes disables the file system WORKAROUND: Use the vxtunefs command to turn off delayed allocation for the file system. * INCIDENT NO:3762919 TRACKING ID:3602082 SYMPTOM: The command tab auto-complete fails for the /dev/vx/ file tree; specifically for RHEL 7 WORKAROUND: Please remove the "bash-completion-2.1-6.el7.noarch" RPM, so that the command tab auto-complete does not fail for the /dev/vx/ file tree. * INCIDENT NO:3762983 TRACKING ID:2438368 SYMPTOM: Delayed allocation sometimes gets turned off automatically when one of the volumes in a multi-volume file system nears 100% usage even if other volumes have free space WORKAROUND: After sufficient space is freed from the volume, delayed allocation automatically resumes. * INCIDENT NO:3762988 TRACKING ID:2560357 SYMPTOM: Task blocked messages display in the console for RHEL5 and RHEL6 WORKAROUND: ou can disable these messages by using the following command: # echo 0 > /proc/sys/kernel/hung_task_timeout_secs * INCIDENT NO:3763244 TRACKING ID:3766074 SYMPTOM: Unmounting the checkpoint using cfsumount(1M) may fail if SElinux is in enforcing mode. WORKAROUND: 1) remove mntlock=VCS from /etc/mtab and retry the cfsumount. 2) To prevent future cfsumount failure follow the below steps : # grep mount.vxfs /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp * INCIDENT NO:3768320 TRACKING ID:2691654 SYMPTOM: On Linux system unable to select ext4 from the FileSystem WORKAROUND: None * INCIDENT NO:3770314 TRACKING ID:3770312 SYMPTOM: arpc.statda in the anfs-utilsa RPM in the various Linux distributions does not properly cleanse the untrusted format strings. WORKAROUND: Update to version 0.1.9.1 of the anfs-utilsa RPM to correct the problem FIXED INCIDENTS: ---------------- PATCH ID:6.2.1.000 * INCIDENT NO:3093833 TRACKING ID:3093821 SYMPTOM: The system panics due to referring freed super block after the vx_unmount() function errors. DESCRIPTION: In the file system unmount process, once Linux VFS calls in to VxFS specific unmount processing vx_unmount(), it doesn't expect error from this call. So, once the vx_unmount()function returns, Linux frees the file systems corresponding super_block object. But if any error is observed during vx_unmount(), it may leave file system Inodes in vxfs inode cache as it is. Otherwise, when there is no error, the file system inodes are processed and dropped on vx_unmount(). As file systems inodes left in VxFS inode cache would still point to freed super block object, so now when these inodes on Inode cache are cleaned up to free or reuse, they may refer freed super block in certain cases, which might lead to Panic due to NULL pointer de-reference. RESOLUTION: Do not return EIO or ENXIO error from vx_detach_fset() when you unmounts the filesystem. Insted of returning error process, drop inode from the inode cache. * INCIDENT NO:3657150 TRACKING ID:3604071 SYMPTOM: With the thin reclaim feature turned on, you can observe high CPU usage on the vxfs thread process. The backtrace of such kind of threads usually look like this: - vx_dalist_getau - vx_recv_bcastgetemapmsg - vx_recvdele - vx_msg_recvreq - vx_msg_process_thread - vx_kthread_init DESCRIPTION: In the routine to get the broadcast information of a node which contains maps of Allocation Units (AUs) for which node holds the delegations, the locking mechanism is inefficient. Thus every time when this routine is called, it will perform a series of down-up operation on a certain semaphore. This can result in a huge CPU cost when many threads calling the routine in parallel. RESOLUTION: The code is modified to optimize the locking mechanism in the routine to get the broadcast information of a node which contains maps of Allocation Units (AUs) for which node holds the delegations, so that it only does down-up operation on the semaphore once. * INCIDENT NO:3657151 TRACKING ID:3513507 SYMPTOM: Filesystem umount() may hang due to deadlock in kernel with the following stack trace and other threads(denoted as T1): vx_async_waitmsg vx_msg_broadcast vx_cwfa_step vx_cwfreeze_common vx_cwfreeze_all vx_freeze vx_detach_fset vx_unmount generic_shutdown_super sys_umount In the meanwhile, a thread(T2) is stuck at down_read: rwsem_down_failed_common rwsem_down_read_failed call_rwsem_down_read_failed down_read do_page_fault page_fault filldir64 vx_readdir_int mntput_no_expire vx_irwlock2 vx_readdir vfs_readdir sys_getdents64 A thread(T3) is waiting for down_write rwsem_down_failed_common rwsem_down_write_failed call_rwsem_down_write_failed down_write sys_munmap A thread(T4) is doing vx_read? vx_active_common_flush vx_read activate_task vfs_read sys_read system_call_fastpath DESCRIPTION: This is a dead lock which involves multiple threads. When the umount thread(T1) is initiated, it blocks all file operations from coming into the filesystem and waits for those active threads to drop the active levels they have. One of the active thread(T2) hits a pagecache which attempts a rw semaphore of the process memory map structure with read mode. However, this semaphore is held by another thread(T4) with read mode, whilst a write request(T3) is waiting in the queue that prevents other read requests from getting the semaphore. The current read user of the semaphore(T4) is requiring the active level of the file system while holding read semaphore. But the file system is frozen by the first thread(T1). RESOLUTION: The code is modified to adjust the active level to avoid the deadlock. * INCIDENT NO:3657152 TRACKING ID:3602322 SYMPTOM: Panic while flushing the dirty pages of the inode with backtrace, do_page_fault error_exit vx_iflush vx_workitem_process vx_worklist_process vx_worklist_thread vx_kthread_init kernel_thread DESCRIPTION: The race between the vx_iflush and vx_ilist_chunkclean on the same inode. The vx_ilist_chunkclean takes the inode and clears the inode pointers while deiniting, which causes NULL pointer dereference in the flusher thread. RESOLUTION: Resolve the race by taking the ilock, along with icache lock, whenever we dereference a pointer in the inode. If the inode pointer is NULL already/deinitialized then goto the next inode and try to flush it. * INCIDENT NO:3657153 TRACKING ID:3622323 SYMPTOM: Cluster Filesystem mounted as read-only panics when it gets sharing and/or compression statistics using the fsadm_vxfs(1M) command with the following stack: - vx_irwlock - vx_clust_fset_curused - vx_getcompstats - vx_aioctl_getcompstats - vx_aioctl_common - vx_aioctl - vx_unlocked_ioctl - vx_ioctl - vfs_ioctl - do_vfs_ioctl - sys_ioctl - system_call_fastpath DESCRIPTION: When file system is mounted as read-only, part of the initial setup is skipped, including loading of few internal structures. These structures are referenced while gathering statistics for sharing and/or compression. As a result, panic occurs. RESOLUTION: The code is modified to only allow "fsadm -HS all" to gather sharing and/or compression statistics on read-write file systems. On read-only file systems, this command fails. * INCIDENT NO:3657156 TRACKING ID:3604750 SYMPTOM: The kernel loops during the extent re-org with the following stack trace: vx_bmap_enter() vx_reorg_enter_zfod() vx_reorg_emap() vx_extmap_reorg() vx_reorg() vx_aioctl_full() $cold_vx_aioctl_common() vx_aioctl() vx_ioctl() vno_ioctl() ioctl() syscall() DESCRIPTION: The extent re-org minimizes the file system fragmentation. When the re-org request is issued for an inode with a lot of ZFOD extents, it reallocates the extents of the original inode to the re-org inode. During this, the ZFOD extent are preserved and enter the re-org inode in a transaction. If the extent allocated is big, the transaction that enters the ZFOD extents becomes big and returns an error. Even when the transaction is retried the same issue occurs. As a result, the kernel loops during the extent re-org. RESOLUTION: The code is modified to enter the Bmap (block map) of the allocated extent and then perform the ZFOD processing. If you get a committable error during the ZFOD enter, then commit the transaction and continue with the ZFOD enter. * INCIDENT NO:3657157 TRACKING ID:3617191 SYMPTOM: Checkpoint creation may take hours. DESCRIPTION: During checkpoint creation, with an inode marked for removal and being overlaid, there may be a downstream clone and VxFS starts pulling all the data. With Oracle it's evident because of temporary files deletion during checkpoint creation. RESOLUTION: The code is modified to selectively pull the data, only if a downstream push inode exists for file. * INCIDENT NO:3657158 TRACKING ID:3601943 SYMPTOM: The block map tree of a file is corrupted across the levels, and during truncating, inode for the file may lead to an infinite loop. There are various DESCRIPTION: For files larger than 64G, truncation code first walks through the bmap tree to find the optimal offset from which to begin the truncation. If this truncation falls within corrupted range of the bmap, actual truncation code which relies on binary search to find this offset. As a result, the truncation cannot find the offset, thus it returns empty. The output makes the truncation code to submit dummy transaction, which updates the inode of file with latest ctime, without freeing the extents allocated. RESOLUTION: The truncation code is modified to detect the corruption, mark the inode bad and, mark the file system for full-fsck. The modification makes the truncation possible for full fsck. Next time when it runs, the truncation code is able to throw out the inode and free the extents. * INCIDENT NO:3657159 TRACKING ID:3633067 SYMPTOM: While converting from ext3 file system to VxFS using vxfsconvert, it is observed that many inodes are missing. DESCRIPTION: When vxfsconvert(1M) is run on an ext3 file system, it misses an entire block group of inodes. This happens because of an incorrect calculation of block group number of a given inode in border case. The inode which is the last inode for a given block group is calculated to have the correct inode offset, but is calculated to be in the next block group. This causes the entire next block group to be skipped when the code attempts to find the next consecutive inode. RESOLUTION: The code is modified to correct the calculation of block group number. * INCIDENT NO:3665980 TRACKING ID:2059611 SYMPTOM: The system panics due to a NULL pointer dereference while flushing the bitmaps to the disk and the following stack trace is displayed: vx_unlockmap+0x10c vx_tflush_map+0x51c vx_fsq_flush+0x504 vx_fsflush_fsq+0x190 vx_workitem_process+0x1c vx_worklist_process+0x2b0 vx_worklist_thread+0x78 DESCRIPTION: The vx_unlockmap() function unlocks a map structure of the file system. If the map is being used, the hold count is incremented. The vx_unlockmap() function attempts to check whether this is an empty mlink doubly linked list. The asynchronous vx_mapiodone routine can change the link at random even though the hold count is zero. RESOLUTION: The code is modified to change the evaluation rule inside the vx_unlockmap() function, so that further evaluation can be skipped over when map hold count is zero. * INCIDENT NO:3665984 TRACKING ID:2439261 SYMPTOM: When the vx_fiostats_tunable is changed from zero to non-zero, the system panics with the following stack trace: vx_fiostats_do_update vx_fiostats_update vx_read1 vx_rdwr vno_rw rwuio pread DESCRIPTION: When vx_fiostats_tunable is changed from zero to non-zero, all the incore-inode fiostats attributes are set to NULL. When these attributes are accessed, the system panics due to the NULL pointer dereference. RESOLUTION: The code has been modified to check the file I/O stat attributes are present before dereferencing the pointers. * INCIDENT NO:3665990 TRACKING ID:3567027 SYMPTOM: During the File System resize operation, the "fullfsck flag is set with the following message:vxfs: msgcnt 183168 mesg 096: V-2-96: vx_setfsflags - /dev/vx/dsk/sfsdg/vol file system fullfsck flag set - vx_fs_upgrade_reorg DESCRIPTION: File system resize requires some temporary inodes to swap the old inode and the converted inode. However, before a structural inode ise processed, the "fullfsck flag is set when a failure occurs during the metadata change. The flag is cleared after the swap is successfully completed. If the temporary inode allocation fails, VxFS leaves the fullfsck flag on the disk. However, all temporary inodes can be cleaned up when not being in use, thus these temporary inodes do not result in corruption. RESOLUTION: The code is modified to clear the fullfsck flag if the structural inode conversion cannot create its temporary inode. * INCIDENT NO:3666007 TRACKING ID:3594386 SYMPTOM: On installing VxFS 5.1SP1RP4P1HF1 on RHEL6u5, system panic occurs when ftrace(1M) is enabled and multiple files are created when large amount of space is consumed. DESCRIPTION: The system panic occurs when the stack overflow happens through the bio_alloc() function that was initiated through a routine. The routine is where the bio_alloc() function exits VxFS and call through the block layer. RESOLUTION: The code is modified by adding a new handoff routine that would hand off the bio_alloc() task to a new worker thread in case the remaining stack was insufficient to proceed. * INCIDENT NO:3666008 TRACKING ID:3616907 SYMPTOM: While performing the garbage collection operation, VxFS causes the non-maskable interrupt (NMI) service to stall. DESCRIPTION: With a highly fragmented Reference Count Table (RCT), when a garbage collection operation is performed, the CPU could be used for a longer duration. The CPU could be busy if a potential entry that could be freed is not identified. RESOLUTION: The code is modified such that the CPU is released after a when it is idle after a specified time interval. * INCIDENT NO:3666010 TRACKING ID:3233276 SYMPTOM: On a 40 TB file system, the fsclustadm setprimary command consumes more than 2 minutes for execution. And, the unmount operation consumes more time causing a primary migration. DESCRIPTION: The old primary needs to process the delegated allocation units while migrating from primary to secondary. The inefficient implementation of the allocation unit list is consuming more time while removing the element from the list. As the file system size increases, the allocation unit list also increases, which results in additional migration time. RESOLUTION: The code is modified to process the allocation unit list efficiently. With this modification, the primary migration is completed in 1 second on the 40 TB file system. * INCIDENT NO:3683470 TRACKING ID:3682138 SYMPTOM: The VxVM symbols are released before the VxFS modules unload time. DESCRIPTION: On RHEL7, the VxFS module receives or adds VxVM symbol as follows: 1. Get or imports all required VxVM symbols on first access or on first mount. Refcnt/hold for VxVM module is incremented through VEKI on symbol_get request so that module doesnt get unloaded. 2. The symbols (imported in step 1) are used as required. 3. VxFS puts/releases VxVM symbols during the VxFS unload time. Refcnt is decremented/hold is released. As a result, VxVM module unloads until the VxFS module is unloaded. Manual upgrade of VxVM pkg cannot happen until the VxFS modules are unloaded RESOLUTION: The code is modified to release VxVM symbols before the VxFS modules unload time. * INCIDENT NO:3687679 TRACKING ID:3685391 SYMPTOM: Execute permissions for a file not honored correctly. DESCRIPTION: The user was able to execute the file regardless of not having the execute permissions. RESOLUTION: The code is modified such that an error is reported when the execute permissions are not applied. * INCIDENT NO:3697142 TRACKING ID:3697141 SYMPTOM: Added support for Sles12 DESCRIPTION: Added support for Sles12 RESOLUTION: Added support for Sles12 * INCIDENT NO:3697966 TRACKING ID:3697964 SYMPTOM: When a file system is upgraded, the upgraded layout clears the superblock flags (fs_flags). DESCRIPTION: When a file system is upgraded, the new superblock structure gets populated with the field values. Most of these values are inherited from the old superblock. As a result, the fs_flags values are overwritten and the flags such as VX_SINGLEDEV are deleted from the superblock. RESOLUTION: The code is modified to restore the old superblock flags while upgrading the disk layout of a file system. * INCIDENT NO:3698165 TRACKING ID:3690078 SYMPTOM: The system panics at vx_dev_strategy() routine with the following stack trace: vx_snap_strategy() vx_logbuf_write() vx_logbuf_io() vx_logbuf_flush() vx_logflush() vx_mapstrategy() vx_snap_strategy() vx_clonemap() vx_unlockmap() vx_holdmap() vx_extmaptran() vx_extmapchange() vx_extprevfind() vx_extentalloc() vx_te_bmap_alloc() vx_bmap_alloc_typed() vx_bmap_alloc() vx_get_alloc() vx_cfs_pagealloc() vx_alloc_getpage() vx_do_getpage() vx_internal_alloc() vx_write_alloc() vx_write1() vx_write_common_slow() vx_write_common() vx_vop_write() vx_writev() vx_naio_write_v2() vfs_writev() DESCRIPTION: The issue was observed due to low handoff limit of vx_extprevfind. RESOLUTION: The code is modified to avoid the stack overflow. * INCIDENT NO:3706864 TRACKING ID:3709947 SYMPTOM: The SSD cache fails to go offline due to additional slashes "//" in the dev path of the cache device. DESCRIPTION: The conv_to_bdev() function authenticates whether a path contains rdsk (character device) or dsk (disk device). If rdsk is present, the fs_convto_bspec() function calls the fs_pathcanon() function to remove the additional slashes. In case the path contains dsk (disk device) then VxFS refuses to call the functions. As a result, the additional slashes appear in the final output path. RESOLUTION: The code is modified to enable VxFS to call the correct functions. * INCIDENT NO:3710794 TRACKING ID:3710792 SYMPTOM: Unmount fails when the mount point contains a special character (colon). DESCRIPTION: For clones, the pseudo device name must contain <devicepath>:<clone name>. Thus, when using the cloned block device, the umount codepath performs an exclusive processing to unmount the device. Sometimes, the mount point itself can be created using the special character (colon). As a result, the mount point splits at the colon. RESOLUTION: The code is modified to unsplit the mount point if it is not a block device and it is a real mount point that can be searched in the mounted file systems table (mtab). * INCIDENT NO:3715567 TRACKING ID:3715566 SYMPTOM: VxFS fails to report an error when the maxlink and nomaxlink options are set for disk layout version (DLV) lower than 10. DESCRIPTION: The maxlink and nomaxlink options allow you to enable and disable the maxlink support feature respectively. The maxlink support feature operates only on DLV version 10. Due to an issue, the maxlink and nomaxlink options wrongly appear in DLV versions lower than 10. However, when selected the options do not take effect. RESOLUTION: The code is modified such that VxFS reports an error when you attempt to set the maxlink and nomaxlink options for DLV version lower than 10. * INCIDENT NO:3716627 TRACKING ID:3622326 SYMPTOM: During a checkpoint promote, a file system is marked with a fullfsck flag because the corresponding inode is marked as bad. DESCRIPTION: The issue was observed because VxFS skipped moving the data to clone inode. As a result, the inode is marked bad during a checkpoint promote and as a consequence the file system is marked with a fullfsck flag. RESOLUTION: The code is modified to move the correct data to the clone inode. * INCIDENT NO:3717895 TRACKING ID:2919310 SYMPTOM: During stress testing on cluster file system, an assertion failure was hit because of a missing linkage between the directory and the associated attribute inode. DESCRIPTION: As per the designed behavior, the node which owns the inode of the file, receives the request to remove the file from the directory. If the directory has an alternate index (hash directory) present, then in the file remove receive handler, the attribute inode is read from the disk. However, VxFS does not create a linkage between the directory and the corresponding inode, which results in an assert failure. RESOLUTION: The code is modified to set the directory inodes i_dirhash field to attribute inode. This change is exercised while bringing the inode incore during file or directory removal. * INCIDENT NO:3718542 TRACKING ID:3269553 SYMPTOM: VxFS returns inappropriate message for read of hole via ODM. DESCRIPTION: Sometimes sparse files containing temp or backup/restore files are created outside the Oracle database. And, Oracle can read these files only using the ODM. As a result, ODM fails with an ENOTSUP error. RESOLUTION: The code is modified to return zeros instead of an error. * INCIDENT NO:3721458 TRACKING ID:3721466 SYMPTOM: After a file system is upgraded from version 6 to 7, the vxupgrade(1M) command fails to set the VX_SINGLEDEV flag on a superblock. DESCRIPTION: The VX_SINGLEDEV flag was introduced in disk layout version 7. The purpose of the flag is to indicate whether a file system resides only on a single device or a volume. When the disk layout is upgraded from version 6 to 7, the flag is not inherited along with the other values since it was not supported in version 6. RESOLUTION: The code is modified to set the VX_SINGLEDEV flag when the disk layout is upgraded from version 6 to 7. * INCIDENT NO:3726403 TRACKING ID:3739618 SYMPTOM: sfcache command with the "-i" option may not show filesystem cache statistic periodically. DESCRIPTION: sfcache command with the "-i" option may not show filesystem cache statistic periodically. RESOLUTION: The code is modified to add a loop to print sfcache statistics at the specified interval. * INCIDENT NO:3727166 TRACKING ID:3727165 SYMPTOM: Enhance RHEV support for SF devices for identification in Guest DESCRIPTION: We need a provision of assigning serial no to a device while attach. This would be passed on as the serial no of the scsi device to the guest. As a result, scsi inquiry on the device should return the provided serial no in Vendor specific data. RESOLUTION: Corresponding changes for supplying the serial number to the vxfs hook is done * INCIDENT NO:3729704 TRACKING ID:3719523 SYMPTOM: 'vxupgrade' does not clear the superblock replica of old layout versions. DESCRIPTION: While upgrading the file system to a new layout version, a new superblock inode is allocated and an extent is allocated for the replica superblock. After writing the new superblock (primary + replica), VxFS frees the extent of the old superblock replica. Now, if the primary superblock corrupts, the full fsck searches for replica to repair the file system. If it finds the replica of old superblock, it restores the file system to the old layout, instead of creating a new one. This behavior is wrong. In order to take the file system to a new version, we should clear the replica of old superblock as part of vxupgrade, so that full fsck won't detect it later. RESOLUTION: Clear the replica of old superblock as part of vxupgrade. * INCIDENT NO:3733812 TRACKING ID:3729030 SYMPTOM: The fsdedupschd daemon failed to start on RHEL7. DESCRIPTION: The dedup service daemon failed to start because RHEL 7 changed the service management mechanism. The daemon uses the new systemctl to start and stop the service. For the systemctl to properly start, stop, or query the service, it needs a service definition file under the /usr/lib/systemd/system. RESOLUTION: The code is modified to create the fsdedupschd.service file while installing the VRTSfsadv package. * INCIDENT NO:3737330 TRACKING ID:3737329 SYMPTOM: Added support for RHEL7.1 DESCRIPTION: Added support for RHEL7.1 RESOLUTION: Added support for RHEL7.1 * INCIDENT NO:3743913 TRACKING ID:3743912 SYMPTOM: Users could create sub-directories more than 64K for disk layouts having versions lower than 10. DESCRIPTION: In this release, the maxlink feature enables users to create sub-directories larger than 64K.This feature is supported on disk layouts whose versions are higher than or equal to 10. The macro VX_TUNEMAXLINK denotes the maximum limitation on sub-directories. And, its value was changed from 64K to 4 billion. Due to this, users could create more than 64K sub-directories for layout versions < 10 as well, which is undesirable. This fix is applicable only on platforms other than AIX. RESOLUTION: The code is modified such that now you can set the value of sub-directory limitation to 64K for layouts whose versions are lower than 10. * INCIDENT NO:3745651 TRACKING ID:3642314 SYMPTOM: Umount operation reports an error code 255 in case of write-back cache. DESCRIPTION: Umount helper binary uses umount or umount2 system calls to unmount VxFS file system. In case of error, these system calls return -1. The umount helper returns this value to the system(OSes) umount binary which interpreted it as 255. RESOLUTION: The code is modified to maintain consistency with the operating systems behavior. In case of umount failure, it must return MOUNT_EX_FAIL which is defined as 32 for RHEL7 and 1 for RHEL6 or SLES11. * INCIDENT NO:3749727 TRACKING ID:3750187 SYMPTOM: Internal noise testing hits debug assert. DESCRIPTION: The issue is observed becasue Linux inodes are not initialized properly. Initialization of Linux inodes are done at some VxFS entry points like vx_lookup. In write back replay, an inode is created based on the inode number in log and similar initialization is required here as well. RESOLUTION: The code is modified to have proper initialization of inodes. * INCIDENT NO:3749776 TRACKING ID:3637636 SYMPTOM: Cluster File System (CFS) node initialization and protocol upgrade may hang during rolling upgrade with the following stack trace: vx_svar_sleep_unlock() vx_event_wait() vx_async_waitmsg() vx_msg_broadcast() vx_msg_send_join_version() vx_msg_send_join() vx_msg_gab_register() vx_cfs_init() vx_cfs_reg_fsckd() vx_cfsaioctl() vxportalunlockedkioctl() vxportalunlockedioctl() And vx_delay() vx_recv_protocol_upgrade_intent_msg() vx_recv_protocol_upgrade() vx_ctl_process_thread() vx_kthread_init() DESCRIPTION: CFS node initialization waits for the protocol upgrade to complete. Protocol upgrade waits for the flag related to the CFS initialization to be cleared. As the result, the deadlock occurs. RESOLUTION: The code is modified so that the protocol upgrade process does not wait to clear the CFS initialization flag. * INCIDENT NO:3755796 TRACKING ID:3756750 SYMPTOM: VxFS may leak memory when File Design Driver (FDD) module is unloaded before the cache file system is taken offline. DESCRIPTION: When FDD module is unloaded before the cache file system is taken offline, few FDD related structures in the cache file system remains to be free. As a result, memory leak is observed. RESOLUTION: The code is modified such that FDD related structure is not initialized for cache file systems. PATCH ID:6.2.0.100 * INCIDENT NO:3703631 TRACKING ID:3615043 SYMPTOM: At times, while writing to a file, data could be missed. DESCRIPTION: While writing to a file when delayed allocation is on, Solaris could dishonour the NON_CLUSTERING flag and cluster pages beyond the range for which we have issued the flushing, leading to data loss. RESOLUTION: Make sure we clear the flag and flush the exact range, in case of dalloc. * INCIDENT NO:3723334 TRACKING ID:3723336 SYMPTOM: On RHEL 6.6, umount(8) system call hangs if an application is watching for inode events using inotify(7) APIs. DESCRIPTION: On RHEL 6.6, additional counters were added in the super block to track inotify watches, these new counters were not implemented in VxFS. Hence while doing umount, the operation hangs until the counter in the superblock drops to zero, which would never happen since they are not handled in VXFS. RESOLUTION: Code is modified to handle additional counters added in RHEL6.6. INCIDENTS FROM OLD PATCHES: --------------------------- NONE