| To: | Stephen Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] xfs: revert to double-buffering readdir |
| From: | Chris Wedgwood <cw@xxxxxxxx> |
| Date: | Fri, 30 Nov 2007 15:04:35 -0800 |
| Cc: | Timothy Shimmin <tes@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx> |
| In-reply-to: | <165B249C-FE97-4B27-927B-B39DE316CB23@xxxxxxx> |
| References: | <20071114070400.GA25708@xxxxxxxxxxxxxxxxxx> <20071125163014.GA17922@xxxxxxxxxxxxx> <474FBA21.4070201@xxxxxxx> <165B249C-FE97-4B27-927B-B39DE316CB23@xxxxxxx> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > Looks like the readdir is in the bowels of the btree code when > filldir gets called here, there are probably locks on several > buffers in the btree at this point. This will only show up for large > directories I bet. I see it for fairly small directories. Larger than what you can stuff into an inode but less than a block (I'm not checking but fairly sure that's the case). > Just rambling, not a single line of code was consulted in writing > this message. Can you explain why the offset is capped and treated in an 'odd way' at all? + curr_offset = filp->f_pos; + if (curr_offset == 0x7fffffff) + offset = 0xffffffff; + else + offset = filp->f_pos; and later the offset to filldir is masked. Is that some restriction in filldir? |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] xfs: revert to double-buffering readdir, Stephen Lord |
|---|---|
| Previous by Thread: | Re: [PATCH] xfs: revert to double-buffering readdir, Stephen Lord |
| Next by Thread: | Possible bug in XFS causing scheduling while atomic BUG in Linux 2.6.23, Rafał Rzepecki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |