On Wednesday, March 6, 2013 at 3:14 PM, Jim Schutt wrote: > When I'm doing these stat operations the file system is otherwise > idle. What's the cluster look like? This is just one active MDS and a couple hundred clients? > What is happening is that once one of these slow stat operations > on a file completes, it never happens again for that file, from > any client. At least, that's the case if I'm not writing to > the file any more. I haven't checked if appending to the files > restarts the behavior. I assume it'll come back, but if you could verify that'd be good. > On the client side I'm running with 3.8.2 + the ceph patch queue > that was merged into 3.9-rc1. > > On the server side I'm running recent next branch (commit 0f42eddef5), > with the tcp receive socket buffer option patches cherry-picked. > I've also got a patch that allows mkcephfs to use osd_pool_default_pg_num > rather than pg_bits to set initial number of PGs (same for pgp_num), > and a patch that lets me run with just one pool that contains both > data and metadata. I'm testing data distribution uniformity with 512K PGs. > > My MDS tunables are all at default settings. > > > > > We'll probably want to get a high-debug log of the MDS during these slow stats as well. > > OK. > > Do you want me to try to reproduce with a more standard setup? No, this is fine. > Also, I see Sage just pushed a patch to pgid decoding - I expect > I need that as well, if I'm running the latest client code. Yeah, if you've got the commit it references you'll want it. > Do you want the MDS log at 10 or 20? More is better. ;) -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
