From: Andreas Dilger <adilger@clusterfs.com>
To: Jan Hudec <bulb@ucw.cz>,
linux-fsdevel@vger.kernel.org, Alexander Viro <viro@math.psu.edu>
Subject: Re: inode rwlock instead of semaphore
Date: Mon, 3 Feb 2003 10:47:36 -0700 [thread overview]
Message-ID: <20030203104736.D18636@schatzie.adilger.int> (raw)
In-Reply-To: <20030203131352.GA7993@vagabond>; from bulb@ucw.cz on Mon, Feb 03, 2003 at 02:13:52PM +0100
On Feb 03, 2003 14:13 +0100, Jan Hudec wrote:
> On Sun, Feb 02, 2003 at 10:01:55AM -0700, Andreas Dilger wrote:
> > One possibility is to change the VFS to use down_read(&dir->i_rwlock) or
> > similar, or alternately create VFS methods that allow pushing the locking
> > down into the filesystem so they could use a rwlock or even a dir+name-based
> > lock (e.g. for ext3+htree) so they can lock subsets of the directory for
> > both read and write operations.
>
> Definitely sure lookup is a reader? AFAICT from the VFS point of view,
> it's a writer and from the disk's point of view the filesystem driver
> and not VFS should do the locking (eg. networking filesystems would only
> do this locking on server).
We have already created an API on the client side which allows the network
filesystem to handle the locking itself, and we are now using the server
side distributed lock manager to totally bypass the VFS locking entirely.
It looks like we don't actually need any changes for our network filesystem,
but it would still be a performance win for local filesystems to be able to
handle locking as needed for maximum performance.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
prev parent reply other threads:[~2003-02-03 17:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-02 17:01 inode rwlock instead of semaphore Andreas Dilger
2003-02-02 17:42 ` Matthew Wilcox
2003-02-02 22:32 ` Andrew Morton
2003-02-03 13:13 ` Jan Hudec
2003-02-03 17:47 ` Andreas Dilger [this message]
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=20030203104736.D18636@schatzie.adilger.int \
--to=adilger@clusterfs.com \
--cc=bulb@ucw.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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).