[BACK]Return to beta_caveats.html CVS log [TXT][DIR] Up to [Development] / xfs-website.orig

File: [Development] / xfs-website.orig / beta_caveats.html (download) (as text)

Revision 1.3, Wed Sep 27 20:40:51 2000 UTC (17 years, 1 month ago) by xfs
Branch: MAIN
Changes since 1.2: +36 -13 lines

*** empty log message ***

<& xfsTemplate,top=>1,side=>1 &>

<!-- Start Project Content -->
<h2>
<b><font face="ARIAL NARROW,HELVETICA">XFS Beta Release Caveats</font></b></h2>

<p>
You must take the following issues into account
when you create and administer
XFS filesystems with the current release of XFS for Linux.
</p>

<h3>Size and Memory Limitations</h3>

<li>
2 Terabyte filesystem limitation

<p>
Currently XFS is limited to filesystems smaller that 2 terabytes.
This is due to limitations in the Linux block device I/O layers.
</p>

<p>
The XFS team is working with Linux developers to improve the Linux
I/O layers. The improvements will include the support neccesary to 
exceed 2 Tbyte filesystems.
</p>

<li>
4 Gbyte memory limitation
<P>
XFS has mostly been tested on machines with less than 1 Gbyte of memory with
highmem support turned off. Highmem kernels with XFS do function, provided the
kio and kiocluster mount options are not used; however, less testing has
been performed in this configuration.
</p>

<h3>Required Compiler and Library Releases</h3>

<li>
gcc version 2.91.66 required
</li>

<p>
Due to known problems with later versions of gcc,
version 2.91.66 must be used when compiling XFS
and the associated kernel.
This is the default compiler on RedHat 6.2 systems.
Other distributions may be using a later version.
The easiest way to check what version is in
use is by running <tt>gcc -v</tt>.
</p>

<li>
glibc version 2.1.3 required
</li>

<p>
The version of glibc primarily used for development and testing 
has been 2.1.3.
Other versions should be considered "status unknown".
</p>

<h3>XFS Features</h3>

<li>
New system calls
</li>

<p>
A preliminary set of system calls to support extended attributes 
has been added. This interface will most likely change as it becomes
more defined and other Linux developers contribute their thoughts.
</p>

<li>
Migrating from non-XFS to XFS 
</li>

<p>
The Linux version of dump and restore can be used to migrate 
data from a non-XFS volume to an XFS volume.
Linux dump, however, cannot be used to dump an XFS volume as it uses
ext2 library functions.
</p>

<li>
Migrating from IRIX XFS to Linux XFS 
</li>

<p>
xfsdump and xfsrestore can be used to migrate an IRIX XFS volume
to a Linux XFS volume and vice versa. However, one needs to set
the block-size explicitly for Linux xfsdump and xfstrestore
to match the block-size used on IRIX. This is done by using the
-b option, and would typically be set to -b 2097152 or to -b 245760
for a remotely dumped IRIX tape. Also, there is currently a bug in
xfsrestore which will cause it to core dump at the end of the
restore if the host does not have any on-disk inventory. If this
happens all the files will be restored but the directory
attributes (modes, permissions and dates) will not be restored.
The work-around is to use the -J option to xfsrestore which will
prevent it from trying to update the on-disk inventory from the tape inventory.
Both of these problems are planned to be fixed in the next release.


</p>

<li>
Backup and Restore
</li>

<p>
xfsdump and xfsrestore should be used for backup and restore
of XFS volumes. xfsdump and xfsrestore currently support
file extents but not extended attributes.
DMAPI and quotas are not yet supported in Linux XFS,
nor are they supported in xfsdump and xfsrestore.
</p>

<h3>XFS Caveats and Limitations</h3>

<li>
XFS version 2 directory format recommended
</li>

<p>
XFS supports two directory formats, referred to as
version 1 and version 2.  For Linux XFS,
the version 2 directory format is strongly recommended.
Due to the way glibc getdents interfaces with the kernel implementation,
XFS version 1 directories can exhibit problems, usually missing directory
entries. By default mkfs will create version 2 directory format filesystems.
</p>

<li>
4k filesystem block size limitation
</li>

<p>
For the current release of XFS, the filesystem block size is limited
to the size of a memory page.  On a x86 architecture that size is 4 Kbytes.
</p>

<p>
Note that files systems created on an IRIX/MIPS platform must have been 
created with a 4 Kbyte block size in order to be mounted on a ia32 Linux system.
File systems not created with a 4k block will fail to mount with an error
indicating the mis-match.
</p>

<li>
Unwritten extents unsupported
</li>

<p>
The unwritten extent feature is not yet operational
and should be turned off when mkfs is executed, using
the following argument to the <tt>mkfs</tt> command:
</p>

<p>
<tt>-d unwritten=0</tt>
</p>

<p>
Currently this is the default setting for mkfs.xfs on Linux.
</p>

<li>
Synchronous I/O unsupported
</li>

<p>
Specifying O_SYNC on open will not have the desired effect. write system
calls can return before data is on disk. fsync will force data out to disk.
This will be fixed in a later beta.
</p>

<li>
Direct I/O is not yet operational. 
</li>

<p> 
It is scheduled for a later beta release.
</p>

<li>
Quotas unsupported 
</li>

<p>
Support for filesystem quotas is not yet operational.
</p>

<li>
Changing filesystem permissions
</li>
<p>
It is possible to remount an XFS filesystem to change its permissions
from read/write to read-only.  This support is needed for
XFS to function as a root filesystem.
</p>
<p> Note:  This operation will most likely result in a hung file system if performed on a busy
partition.
</p>

<li>
Issues with filesystem remounts
</li>

<p>
Issuing the remount call to a non-busy XFS filesystem does not always
work correctly. The usual result will be a hung processes.  The
occurs primarily when executing the
mount -o remount command.
</p>

<p>
Mounting files using the loop filesystem on an XFS partition does not work 
and usually results in a system panic.
</p>

<br>


<& xfsTemplate,bottom=>1 &>