On Mon, Aug 01, 2011 at 01:25:35PM +1000, Daniel Carosone wrote: > To be clear, the system I was working on the other day is now running > with a normal ashift=9 pool, on a mirror of WD 2TB EARX. Not quite > what I was hoping for, but hopefully it will be OK; I won't have much > chance to mess with it again for a little while.
That turned out to be a false hope. The system is almost unusable. Soon after anything creates a lot of metadata updates, it grinds into the ground doing ~350 write iops, 0 read, forever trying to write them out. Processes start blocking on reads and/or txg closes and the system never comes back. rsync and atimes were the first and worst culprit, but atime=off wasn't enough to prevent it competely. It can't just be that these are slow to write out, because I would expect it to eventually finish. I suspect something else is going on here. Would zfs re-issue writes if they haven't gotten to the disk yet, somehow? I'm not talking about ata commands timing out, but something at a higher level making a long queue worse. I'll have to find time to convert this bac to ashift=12 and try your boot blocks soon. -- Dan.
pgprF69UOwUKr.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
