On 03/06/2013 05:18 PM, Greg Farnum wrote: > 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? 1 mds, 1 mon, 576 osds, 198 cephfs 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. OK, I'll check it out. > > >> 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. ;) OK, thanks. -- Jim > > > -- 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
