From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH, RFC] ext4: remove ext4_dir_llseek
Date: Thu, 26 Apr 2012 13:13:35 -0500 [thread overview]
Message-ID: <4F99904F.3040000@redhat.com> (raw)
In-Reply-To: <4F984F22.10203@redhat.com>
On 4/25/12 2:23 PM, Eric Sandeen wrote:
> ext4_dir_llseek() was recently added as part of a patch to allow
> returning 64-bit name hashes. However, reworking _llseek() is not
> necessary to achieve that goal. One unfortunate side effect of the
> change is that it cut&pasted VFS code back into ext4, after Andi
> had just removed other _llseek cut&paste in ext4 by extending the
> VFS functionality.
>
> It also re-introduced i_mutex locking in the dir llseek paths,
> un-doing the upstream (mostly) lockless llseek changes from Andi
> in this case.
>
> Because of the above reasons, and because it introduces new
> EINVAL returns which were not there before, and because SEEK_END+offset
> behaves differently from SEEK_SET w.r.t. offset limits, and because
> it's not clear what problem this is solving, remove it for now.
>
> (NFS only uses SEEK_SET and SEEK_CUR, so changes to SEEK_END shouldn't
> affect it.)
>
> If & when a problematic and testable real-world use case is described,
> this can be re-fixed properly, possibly by expanding the VFS _llseek()
> functions to handle custom EOF offsets for cases such as this.
Self-NAK. Realized this won't work for non-extent dirs, because the
generic llseek will EINVAL for hash "offsets" larger than the max_bitmap_bytes
value. Will send something a little less drastic.
-Eric
next prev parent reply other threads:[~2012-04-26 18:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 19:23 [PATCH, RFC] ext4: remove ext4_dir_llseek Eric Sandeen
2012-04-26 18:13 ` Eric Sandeen [this message]
2012-04-26 22:34 ` [PATCH] ext4: call vfs llseek code from ext4_dir_llseek Eric Sandeen
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=4F99904F.3040000@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.