What version? File a bugzilla (oss.oracle.com/bugzilla) with all the version details, etc. Easier to track issues that-a-way.
mike wrote: > Here's another issue: > > I have a client with 9049 files/dirs in a specific dir. The first time > I did an ls /that/dir/ it froze up - and hitting control C actually > made it behave interestingly. > > Every two times I hit control C, I got one of these permission denied > lines (the files exist, I can open them, I can edit them, I am root, > too) > > [EMAIL PROTECTED] ~]# ls /home/mark/web/domain.com/ > ls: cannot access /home/mark/web/domain.com/file32.htm: Permission denied > ls: cannot access /home/mark/web/domain.com/file4444.htm: Permission denied > > etc. > > Also I am seeing in my webserver log once in a while: > > 2008/04/21 18:10:09 [crit] 6917#0: *1256684 stat() > "/home/mike/web/michaelshadle.com/" failed (13: Permission denied), > client: 1.2.3.4, server: michaelshadle.com, request: "GET / HTTP/1.0", > host: "michaelshadle.com" > > a stat() call fails on a directory, and that directory not only > exists, it's readable and behaves properly 99.999% of the time. these > random stat() failures are a bit odd. However, this hasn't thrown an > error on my proxy server, which is nice. But it is something I am > worried about. I can stat it in shell: > > [EMAIL PROTECTED] web]# stat /home/mike/web/michaelshadle.com/ > File: `/home/mike/web/michaelshadle.com/' > Size: 4096 Blocks: 64 IO Block: 32768 directory > Device: 811h/2065d Inode: 135710860 Links: 15 > Access: (0711/drwx--x--x) Uid: ( 1000/ mike) Gid: ( 1000/ mike) > Access: 2008-03-25 04:27:52.000000000 -0700 > Modify: 2008-03-04 02:17:22.000000000 -0800 > Change: 2008-03-27 04:45:57.000000000 -0700 > [EMAIL PROTECTED] web]# > > Does anything there look out of place? Nothing shows up in dmesg or > any of my /var/log/* logs... > > > On 4/21/08, Herbert van den Bergh <[EMAIL PROTECTED]> wrote: > >> Does the web server that the proxy server talks to have any extended >> debugging you can turn on? In particular, would it be able to log >> timestamps of things it does, so you can narrow down where the hic-up >> occurs? A brute force method to do this would be to run strace -T on all >> server processes, and look for things that take much longer than they >> should, like disk reads exceeding 100ms, or other syscalls taking much >> longer than usual. Ideally you'd have some timing around code you suspect, >> and log a message if the time exceeds some configurable limit. >> >> Thanks, >> Herbert. >> _______________________________________________ Ocfs2-users mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-users
