I believe in the FAQ/man-info page for xfs_fsr, it refers to the fact
that it will only work on file data and that the percent of frag is a
factor of the size of files, number of inodes, and number of files.
This is important because if you run a mail/news/file server of some
sort, and you have *high* frag, then there's probably a performance
problem there.
If you have large files, say, 2GB files, and have tons of them, (read
RDBMS), then each file if it were fragged, would yield a higher amount
of fragmentation per file. Just remember that when using FSR. ;)
Austin
Linda A. Walsh wrote:
> XFS_FSR has been very stable -- I've been running it since before
> xfs was merged into the kernel.
>
> I have the following file, named "fsr" in my /etc/cron.daily:
> fsr:
> #!/bin/bash
> /usr/sbin/xfs_fsr
> ----
> I would think /bin/sh or /bin/sh would work equally well.
>
> _File_ fragmentation is a virtual non-issue on my disks, however,
> xfs_fsr only works on my file data. It doesn't work
> on directory data. On a 118G partition nearing 79% capacity,
> printing the defragmentation data from xfs_db:
>
> files:
> actual 316870, ideal 316652, fragmentation factor 0.07%
>
> directories:
> actual 2538, ideal 1330, fragmentation factor 47.60%
>
> I don't know about other data types (attr, symlink, quota,
> realtime, realtime control) as I don't believe I have
> any of those types on my volumes...But, hey, file fragmentation
> seems to be handled! :-)
>
> Linda
>
>
> Fong Vang wrote:
>
> >This is very useful. Thank you. How stable is xfs_fsr?
> >
>
[[HTML alternate version deleted]]
|