On Wed, Apr 09, 2003 at 06:53:47PM -0400, Greg Freemyer wrote:
> I will add a fragmentation test. If it is too bad I will log/e-mail
> and run xfs_fsr.
xfs_fsr is a terrible tool in a sense
people see it and think 'ah cool, lets defragment my filesystem... we
do this in windows and thats good'
by and large, xfs shouldn't need lots of defragmentation --- that
said, NFS users do see lots of fragmentation at present because
synchronous writes don't preallocate presently
> ie. this would not be useful:
>
> create readonly snapshot
> if [xfs_repair -n snapshot != 0]
> email admin
it's pointless mostly
"xfs_repair -n" will miss things that it otherwise would detect on a
RW fs
also, you need to consider this is a very slow process... how big is
your fs anyhow?
> 2) With a read/write snapshot, something like the below may work.
>
> Weekly (or monthly)
>
> create r/w snapshot
> mount snapshot r/w (and repair any issues caused by the snapshot process)
> unmount snapshot
> if (xfs_repair != 0)
> email admin
if the snapshot is created with xfs_freeze, then I think the log will
be in an active state you you'll want xfs_replair -L
> Updating the script seems easy enough, but if r/w snapshots are
> needed to run/test it, I doubt I will make the effort. (i.e. I
> think you need a DM enabled kernel for that, right?)
i think you need to consider what you're trying to achieve here
there are multi-TB and probably multi-PB XFS filesystems in use and
they don't do these sorts of extreme things (nor could they when the
fs gets that large) --- it's better to address the problems if you
find them
--cw
|