LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephen Lord <lord@xfs.org>
To: Chris Wedgwood <cw@f00f.org>
Cc: Timothy Shimmin <tes@sgi.com>,
	Christoph Hellwig <hch@infradead.org>,
	linux-xfs@oss.sgi.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xfs: revert to double-buffering readdir
Date: Sat, 1 Dec 2007 07:04:27 -0600	[thread overview]
Message-ID: <A3093599-2967-4969-BFFD-1328D47FAC12@xfs.org> (raw)
In-Reply-To: <20071130230435.GA12626@puku.stupidest.org>


On Nov 30, 2007, at 5:04 PM, Chris Wedgwood wrote:

> 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).

I told you I did not read any code..... once a directory is out of  
the inode
and into disk blocks, there will be a lock on the buffer while the  
contents
are copied out.

>
>> 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?

Too long ago to remember exact reasons. The only thing I do recall is  
issues
with glibc readdir code which wanted to remember positions in a dir  
and seek
backwards. It was translating structures and could end up with more
data from the kernel than would fit in the user buffer. This may have  
something
to do with that and special values used as eof markers in the  
getdents output
and signed 32 bit arguments to lseek. In the original xfs directory  
code, the
offset of an entry was a 64 bit hash+offset value, that really  
confused things
when glibc attempted to do math on it.

I also recall that the offsets in the directory fields had different  
meanings
on different OS's. Sometimes it was the offset of the entry itself,  
sometimes it
was the offset of the next entry, that was one of the reasons for the  
translation
layer I think.

Steve


  reply	other threads:[~2007-12-01 13:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14  7:04 2.6.24-rc2 XFS nfsd hang Chris Wedgwood
2007-11-14  7:43 ` Benny Halevy
2007-11-14 12:59   ` J. Bruce Fields
2007-11-14 22:31     ` Christian Kujau
2007-11-15  7:51       ` 2.6.24-rc2 XFS nfsd hang / smbd too Christian Kujau
2007-11-15 14:44         ` Christian Kujau
2007-11-15 22:01         ` Christian Kujau
2007-11-16  0:34         ` Chris Wedgwood
2007-11-16  9:17           ` 2.6.24-rc2 XFS nfsd hang Christian Kujau
2007-11-16 11:03             ` Chris Wedgwood
2007-11-16 14:19               ` Trond Myklebust
2007-11-16 21:43                 ` Chris Wedgwood
2007-11-18 14:44                   ` Christian Kujau
2007-11-18 15:31                     ` Justin Piszcz
2007-11-18 22:07                       ` Christian Kujau
2007-11-14 11:49 ` 2.6.24-rc2 XFS nfsd hang --- filldir change responsible? Chris Wedgwood
2007-11-14 22:48   ` Christian Kujau
2007-11-14 15:29 ` 2.6.24-rc2 XFS nfsd hang Christoph Hellwig
2007-11-14 17:39   ` J. Bruce Fields
2007-11-14 17:44     ` Christoph Hellwig
2007-11-14 17:53       ` J. Bruce Fields
2007-11-14 18:02         ` Christoph Hellwig
2007-11-14 18:08           ` J. Bruce Fields
2007-11-21 15:07             ` Christoph Hellwig
2007-11-21 19:03               ` J. Bruce Fields
2007-11-25 16:30 ` [PATCH] xfs: revert to double-buffering readdir Christoph Hellwig
2007-11-27 19:43   ` Chris Wedgwood
2007-11-29 23:45   ` Christian Kujau
2007-11-30  7:47     ` David Chinner
2007-11-30  7:22   ` Timothy Shimmin
2007-11-30 22:36     ` Stephen Lord
2007-11-30 23:04       ` Chris Wedgwood
2007-12-01 13:04         ` Stephen Lord [this message]
2007-12-03 15:11       ` Christoph Hellwig
2007-12-03 15:09     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A3093599-2967-4969-BFFD-1328D47FAC12@xfs.org \
    --to=lord@xfs.org \
    --cc=cw@f00f.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=tes@sgi.com \
    --subject='Re: [PATCH] xfs: revert to double-buffering readdir' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).