Technical data

Fails to Sync File System on Panic (6250422)
If a host panics with le system I/O occurring to a target, which is connected by using the Solaris
iSCSI software initiator, the I/O might not be able to ush or sync to the target device. This
inability to ush or sync might cause le system corruption. No error message is displayed.
Workaround:
Use the journaling le system like UFS. Starting with Solaris 10, UFS logging is enabled by
default. For more information about UFS, see
“What’s New in File Systems?” in System
Administration Guide: Devices and File Systems
.
Upgrading From Some Solaris Express or Solaris 10
Releases Requires Remounting of File Systems
After you upgrade an NFSv4 server from Solaris Express 6/05 to Solaris Express 7/05 or later
(including all Solaris 10 updates), your programs might encounter EACCES errors.
Furthermore, directories might erroneously appear to be empty.
To prevent these errors, unmount and then remount the client le systems. In case unmounting
fails, you might need to forcibly unmount the le system by using umount -f. Alternatively, you
can also reboot the client.
NFSv4 Access Control List Functions MightWork
Incorrectly
NFSv4 Access Control List (ACL) functions might work improperly if clients and servers in the
network are installed with dierent previous Solaris 10 releases. The aected ACL functions and
command-line utilities that use these functions are the following:
■
acl()
■
facl()
■
getfacl
■
setfacl
For more information about these functions and utilities, see their respective man pages.
For example, errors might be observed in a network that includes the following conguration:
■
A client that is running Solaris 10 Beta software
■
A server that is running Solaris 10 software
The following table illustrates the results of the ACL functions in client-server congurations
with dierent Solaris 10 releases.
File Systems
Solaris 10 5/08 Release Notes • April 200860