xfs
[Top] [All Lists]

Extreme fragmentation when backing up via NFS

To: xfs@xxxxxxxxxxx
Subject: Extreme fragmentation when backing up via NFS
From: Phil Karn <karn@xxxxxxxxxxxx>
Date: Thu, 13 Jan 2011 05:15:52 -0800
In-reply-to: <4D2E3B38.6010506@xxxxxxxxxxx>
References: <4D0C9A4F.4040108@xxxxxxxxxxx> <20101220001024.GH5193@dastard> <4D0EC5C5.2070407@xxxxxxxxxxx> <20101220045126.GK5193@dastard> <20101220105547.4f9e7218@xxxxxxxxxxxxxx> <4D2E3B38.6010506@xxxxxxxxxxx>
Reply-to: karn@xxxxxxxx, karn@xxxxxxxx
Sender: Phil Karn <karn@xxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
I have been backing up my main Linux server onto a secondary machine via
NFS. I use xfsdump like this:

xfsdump -l 9 -f /machine/backups/fs.9.xfsdump /

Over on the server machine, xfs_bmap shows an *extreme* amount of
fragmentation in the backup file. 20,000+ extents are not uncommon, with
many extents consisting of a single allocation block (8x 512B sectors or
4KB).

I do notice while the backup file is being written that holes often
appear in the extent map towards the end of the file. I theorize that
somehow the individual writes are going to the file system out of order,
and this causes both the temporary holes and the extreme fragmentation.

I'm able to work around the fragmentation manually by looking at the
estimate from xfsdump of the size of the backup and then using the
fallocate command locally on the file server to allocate more than that
amount of space to the backup file. When the backup is done, I look at
xfsdump's report of the actual size of the backup file and use the
truncate command locally on the server to trim off the excess.

Is fragmentation on XFS via NFS a known problem?

<Prev in Thread] Current Thread [Next in Thread>