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@xxxxxxxxxx>
Technical Manager
Simplex SRL, Bucharest
Attachment:
xfssyncd_debug.tar.bz2
Description: BZip2 compressed data
Attachment:
pgpapy_Yq2v0m.pgp
Description: PGP signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
