xfssyncd and disk spin down

[Petre Rodan]

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 arround
# 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}"
        ) &
    }

done


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: http://incoming.avira.com/NOSYNC/peter/xfssyncd_debug.tar.bz2

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 anytime.

> 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 2.6.36.2 that you might come up with.

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

Happy Holidays everyone.

cheers,
peter

-- 
petre rodan
<petre.rodan at simplex.ro>
Technical Manager
Simplex SRL, Bucharest
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfssyncd_debug.tar.bz2
Type: application/x-bzip2
Size: 26065 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20101225/aca36395/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20101225/aca36395/attachment.sig>