> Hi everyone,
>
> I remember a message awhile back saying that the benefits of setting the
> mount option biosize=13 plus more would be incorporated in development
> versions of XFS. So I'm wondering, will it still be benefitial on an ia32
> machine to mount an XFS filesystem using the "biosize=13" option if the
> system is running on Linux kernel 2.4.4 with the following
> linux-2.4.4-xfs-cvs-05022001 patch?
This patch will not remove the need for biosize - you will need to apply
this patch to a 2.4.4 tree and then do a cvs update to get the current
code base. I will ask Russell to update the patch with some more recent
ones, there have been sufficient changes since May 2nd I think.
Steve
>
> Also, would there be any tips related to performance when creating the XFS
> filesystem? For example, should a certain option be used of most of the
> files will be small, a certain option for mixed large files and small
> files, et al. The same question goes for mount points. Or maybe someone
> has a website with XFS performance tips? I remember someone else asking
> this question awhile back, too.
For mkfs options, there is not a lot you can do right now, the most useful
option would be the blocksize, but this is currently fixed at the pagesize.
One option which may make a difference is -i size=xxx the default inode
size is 256 bytes, you can make it bigger (upto 4K) this will mean that
more directories will keep their contents in the inode and need less
disk I/O to read and write (but inodes will conversly need more I/O
to read, since inodes are read and written in clusters this is not a
straightfoward calculation). Since extents are also held in the inode
if there is room, this also reduces the number of files which have out
of inode metadata.
Another option I have found makes a difference in the performance of
the filesystem is the log size: -l size=xxxb A larger log means that
when there is a lot of metadata activity, there is more time before
modified metadata has to be flushed to disk to make room in the log
for later changes. However, a larger log also slows down recovery.
Finally for really large filesystems, you want to keep the agcount as
low as possible (-d agcount=) An allocation group can be upto 4Gbytes in
size, more allocation groups means more of them to scan in low free
space conditions. The allocation group size also governs the maximum
extent size you can have in a file. There are some changes in the Irix
version which will show up on linux shortly which will make the ag
options in mkfs easier to use - right now they are very non-intuitive.
At mount time, there are really three options which will make a difference
o biosize (in the released tree the default is 16 or 64K, in the
development tree the default is 12 or 4K). Making this larger
may help some applications, it will hinder others.
o osyncisdsync - indicates that O_SYNC is treated as O_DSYNC, which
is the behavior ext2 gives you by default. Without this option,
O_SYNC file I/O will sync more metadata for the file.
o logbufs=4 or logbufs=8, this increases (from 2) the number of
in memory log buffers. This means you can have more active
transactions at once, and can still perform metadata changes
while the log is being synced to disk. The flip side of this
is that the amount of metadata changes which may be lost on
crash is greater.
Steve
p.s. maybe this should go in the FAQ
>
> I hope you all don't mind the questions. I'm in an asking mood today.
> Thanks a lot in advance for the help!
>
> --> Jijo
>
|