[Top] [All Lists]

Re: xfssyncd and disk spin down

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: xfssyncd and disk spin down
From: Petre Rodan <petre.rodan@xxxxxxxxxx>
Date: Sat, 25 Dec 2010 14:09:48 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4D14E3D2.4000505@xxxxxxxxxxx>
References: <20101223165532.GA23813@xxxxxxxxxxxxxxxx> <4D14E3D2.4000505@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
Hi Eric,

On Fri, Dec 24, 2010 at 12:17:54PM -0600, Eric Sandeen wrote:
> Doesn't seem like that should happen.

music to my ears :)
having this fixed would make me a happy bunny.

> >   8,16   1    36591  6306.873151576  1352  A WBS 976985862 + 2 <- (8,17) 
> > 976985799
> > 
> > there was no file at or near the 976985799 inode (I presume that's an
> > inode?)
> Nope that's a sector on the drive.

great, this should make debugging easier.

> I think we just need to figure out what's causing the writes, and
> what's being written.

not sure about the first thing, but do read on for the "what's written" chapter:

# mount -o remount /dev/sdb1        # to start fresh with no xfssyncd's poking 
# cp -r /usr/src/linux* /mnt/space  # do some writes to the drive, then let it 
completely unused for at least 30 minutes after the cp finished
                                    # at this point the only thing active on 
sdb1 is xfssyncd at 36s intervals
# bin/blk_debug.sh > /dev/shm/stdout

blk_debug.sh parses the output of blktrace, blkparse and for each line 
containing 'A WBS' it uses dd to save 8 sectors from sdb starting with the 
mapped value I get from blkparse

blktrace -d /dev/sdb -o - | blkparse -i - | while read line; do
    echo "${line}"
    grep -q 'A WBS' <<< ${line} && {
        sect=$(echo "${line}" | awk '{ print $8 }' )
        # fork a dd and let xfssyncd time to finish writing
            sleep 20
            # force dd to read the drive, not a cache
            echo 3 > /proc/sys/vm/drop_caches
            dd if=/dev/sdb of=/dev/shm/dump_${sect} skip=${sect} bs=512 count=8 
&& \
                echo "* sectors ${sect}-$((${sect}+8)) saved into dump_${sect}"
        ) &


I thought that since xfssyncd writes to sectors in increments of 2 it would be 
possible to run a diff between 2 consecutive samples and get some information 
that may help you see something. I provide an attachment with the entire 
stdout, sector dumps and scripts. also available here: 

there might be a slight misalignment of a few sectors between dd's seek and 
where it's been told to go, look closely at the blkparse. apparently xfssyncd 
is not 'appending' information, it looks more like a bucketload of a 
similarly-looking array of data each time.

hope this helps, if there is anything amiss I could fix it and try again 

> On an idle fs though I wouldn't expect that we need any of this, so probably
> need to dig a little to see what's going on.  I don't think you need a mount
> option, I think we need an explanation and maybe a bugfix.  :)
> I'll try to find time to look into it unless someone else knows what's going
> on off the top of their heads.

thank you for your interest.
I'll be glad to test kernel patches against that you might come up 

@Stan, thanks for your input, it's nice to see friendly communities gathered 
arround a mailing list again.

Happy Holidays everyone.


petre rodan
Technical Manager
Simplex SRL, Bucharest

Attachment: xfssyncd_debug.tar.bz2
Description: BZip2 compressed data

Attachment: pgpYRuwQbP4bD.pgp
Description: PGP signature

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