From: Alex Tomas <alex@clusterfs.com>
To: Jan Blunck <j.blunck@tu-harburg.de>
Cc: Alex Tomas <alex@clusterfs.com>,
Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
Linux-Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] pdirops: vfs patch
Date: Tue, 22 Feb 2005 15:04:06 +0300 [thread overview]
Message-ID: <m3vf8kx0ll.fsf@bzzz.home.net> (raw)
In-Reply-To: <1109073273.421b1d7923204@webmail.tu-harburg.de> (Jan Blunck's message of "Tue, 22 Feb 2005 12:54:33 +0100")
>>>>> Jan Blunck (JB) writes:
>> 1) i_sem protects dcache too
JB> Where? i_sem is the per-inode lock, and shouldn't be used else.
read comments in fs/namei.c:read_lookup()
>> 2) tmpfs has no "own" data, so we can use it this way (see 2nd patch)
>> 3) I have pdirops patch for ext3, but it needs some cleaning ...
JB> I think you didn't get my point.
JB> 1) Your approach is duplicating the locking effort for regular filesystem
JB> (like ext2):
JB> a) locking with s_pdirops_sems
JB> b) locking the low-level filesystem data
JB> It's cool that it speeds up tmpfs, but I don't think that this legatimate the
JB> doubled locking for every other filesystem.
JB> I'm not sure that it also increases performance for regular filesystems, if you
JB> do the locking right.
we've already done this for ext3. it works.
it speeds some loads up significantly.
especially on big directories.
and you can control this via mount option,
so almost zero cost for fs that doesn't support pdirops.
JB> 2) In my opinion, a superblock-wide semaphore array which allows 1024
JB> different (different names and different operations) accesses to ONE single
JB> inode (which is the data it should protect) is not a good idea.
yes, it has some weakness, i'm reworking vfs patch to avoid inter-inode
collisions.
thanks, Alex
next prev parent reply other threads:[~2005-02-22 12:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-22 11:54 [RFC] pdirops: vfs patch Jan Blunck
2005-02-22 12:04 ` Alex Tomas [this message]
2005-02-22 13:00 ` Jan Blunck
2005-02-22 13:23 ` Alex Tomas
2005-02-22 13:41 ` Jan Blunck
2005-02-23 13:55 ` Alex Tomas
-- strict thread matches above, loose matches on Subject: below --
2005-02-19 17:57 [RFC] parallel directory operations Alex Tomas
2005-02-19 18:04 ` [RFC] pdirops: vfs patch Alex Tomas
2005-02-20 23:35 ` Jan Blunck
2005-02-20 23:43 ` Alex Tomas
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=m3vf8kx0ll.fsf@bzzz.home.net \
--to=alex@clusterfs.com \
--cc=j.blunck@tu-harburg.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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 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).