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
xfssyncd_debug.tar.bz2
Description: BZip2 compressed data
pgpYRuwQbP4bD.pgp
Description: PGP signature
|